Sourcemaps 'unhelpful' when selector generated via mixin

[runningskull]

trafficstars

Apologies if this has been discussed before. I didn't see it.

When using a mixin to generate a selector, the sourcemap for the the generated CSS points to the mixin's file/line, rather than the file that called the mixin. This means if you make heavy use of mixins to generate selectors, the sourcemaps become largely unhelpful when trying to debug a page.

Here's a sample repo w/ a minimal test-case: https://github.com/runningskull/sass-mixin-sourcemaps

I haven't tested this in other sass implementations to compare behaviors, and again I'm not sure this is technically incorrect, hence calling it "unhelpful". Happy to provide any more info or thoughts.

<3 libsass. cheers!

---

EDIT: this is libsass 3.3.2 (used via gulp/node-sass)

[xzyfer]

Please compare this to Ruby Sass. If it's significantly different we can look into. We have no intention of differing from the Ruby Sass behaviour.

[mgreter]

Ruby sass does the same as we do. I agree that this could be usefull since you should be able to reach the mixin body by following a property (AFAIK only possible in chrome so far).

[paulirish]

FWIW here's the visualization of this example

[mgreter]

@paulirish do you have any recommendations how we should handle this? My last conclusion was that we could wrap the resulting selector (.foobar-ext) with another mapping for the actual @include call (we actually will have to apply that to every selector inside the mixin). I guess that should be interpreted as wished by OP in each browser. In chrome we can still quite easily get to the correct selectors/blocks by following the properties in the inspector. But I think this will not work in any other browser so far (might have changed in the meantime). So there we would loose the mapping to where the selector (and its properties) are defined. That's why I haven't progressed this issue yet ...

FYI: Here the equivalent "visualization" in libsass sourcemap inspector - live.

[mcMickJuice]

Hello,

Has there been any headway on this issue? We use a BEM mixin as a helper to generate all of our bem styling. as it currently stands sourcemaps are unusable with this approach.

i understand this is a hard problem and I appreciate any and all work you do you on this issue.

[paulirish]

cc @aslushnikov for his guidance on handling this sourcemap issue.

[kgcreative]

Following this issue, as I'm running into the same thing. I'm temporarily getting around this by injecting some non-standard CSS during development, but that makes me feel unclean.

[kgcreative]

@paulirish - So, interesting discovery today while I was testing this out:

// source-map-test.scss
@mixin source-map-test {
 display: block;
}

// properties
my-element {
 @include source-map-test;
}

The above code will output a source map, with my-element being credited to source-map-test.scss

HOWEVER

// source-map-test.scss
@mixin source-map-test {
 display: block;
}

// properties
my-element {
 /*!*/
 @include source-map-test;
}

Adding an empty important comment before the mixin call, will result in a source map that credits my-element to my-element-source-file.scss (adding a normal comment // or /* */ doesn't work. But /*!*/ does work.)

Tested with node-sass via grunt-sass-2.0.0

I have no idea why this works.

[generalov]

@kgcreative Looking at the http://sass-lang.com/documentation/file.SASS_REFERENCE.html#comments

When the first letter of a multiline comment is !, the comment will always rendered into css output even in compressed output modes.

The /*!*/ comments are preserved on the output. For example:

Common case

Input SCSS

%foo {
  color: red
}
.bar {
  @extend %foo;
}
.baz {
  @extend %foo;
}

Output CSS

.bar,
.baz {
  color: red;
}

Use /*!*/ comments

Input SCSS

%foo {
  color: red
}
.bar {
  /*!*/
  @extend %foo;
}
.baz {
  /*!*/
  @extend %foo;
}

Output CSS

.bar,
.baz {
  color: red;
}
.bar {
    /*!*/
}
.baz {
    /*!*/
}

The additional selectors are kept in the output. The Chrome inspector displays these rules. They are empty but included in Source Maps so the navigation is possible.

[mold]

Still having this problem when generating BEM selectors with mixins. @kgcreative's solution didn't work using [email protected] and [email protected].

Any updates/ideas/recommendations?

[ksylor]

Chiming in to say that fixing this and/or having a workaround to trace back to the use of the mixin rather than the mixin itself would be super useful for some css analysis work my team is doing. Thanks!

[xzyfer]

More discussion in https://twitter.com/ksylor/status/971774023964250112

[xxvii]

Same problem here. I switched from the Ruby generated sass to node/libsass generated sass.

The Ruby source maps show the row number relative to the css rule, while the libsass ones the row of the mixin that generated the selector, which is completely unuseful.

If iI want to know where a mixin is, all I have to do is a simple text search, but finding a specific css rule in a scss is way more complicated.

Besides, Google Chrome's inspector shows the correct css rule row (and not the mixin row) while Firefox shows the mixin row with the same libsass generated source map. Why is that?

[xxvii]

So...no news about that? Firefox still shows the mixin's row number instead of the rule's row number.

[MattCozendey]

Updates?