Why doesn't chrome understand my scss source map?

Question

I have an scss source file named style.scss which resides within /style:

@import 'reset';

body {
  background: #555555;
  color: white;
}

And another scss source file named reset.scss which resides within /style:

* {
  padding: 0;
  margin: 0;
}

These are compiled by sass with a source map in to style.min.css which resides within /style:

*{padding:0;margin:0}body{background:#555555;color:white}

/*# sourceMappingURL=style.min.css.map */

This is the resulting map file, style.min.css.map which resides in /style:

{"version":3,"sources":["reset.scss","style.scss"],"names":[],"mappings":"AAAA,CAAC,AAAC,CACA,OAAO,CAAE,CAAE,CACX,MAAM,CAAE,CAAE,CCAZ,ADCC,ICDG,AAAC,CACH,UAAU,CAAE,OAAQ,CACpB,KAAK,CAAE,KAAM,CACd","file":"style.min.css","sourcesContent":["* {\r\n  padding: 0;\r\n  margin: 0;\r\n}","@import 'reset';\r\n\r\nbody {\r\n  background: #555555;\r\n  color: white;\r\n}\r\n"],"sourceRoot":"/style"}

I am using gulp to invoke sass. Here is the relevant configuration:

var gulp = require('gulp');
var rename = require('gulp-rename');
var sourcemaps = require('gulp-sourcemaps');
var sass = require('gulp-sass');

gulp.task('css', function() {
    return gulp.src('style/style.scss')
        .pipe(sourcemaps.init())
        .pipe(sass({outputStyle: 'compressed'}))
        .pipe(rename({suffix: '.min'}))
        .pipe(sourcemaps.write('.', {addComment: true, sourceRoot: '/style'}))
        .pipe(gulp.dest('style/'))
});

WebStorm 11.0.1 seems to understand this perfectly.

Chrome DevTools fails to understand the mapping correctly. It is clearly trying; but all mappings point to reset.scss in various locations rather than the correct file and location. If I manually combine both files by replacing the @import with the actual content of reset.scss, the mappings work correctly in chrome, pointing to the correct location within style.scss.

Any idea what could be going on here?

EDIT: Microsoft Edge (the new IE in Windows 10) understands the mappings correctly within its in-browser dev tools.

EDIT 2: Firefox is experiencing the same issue as Chrome in exactly the same way.

EDIT 3: I Added another scss source file, test.scss:

div {
  color: red;
}

I then imported this in to the style.scss file which now looks like this:

@import 'reset';
@import 'test';

body {
  background: #555555;
  color: white;
}

Chrome seems to understand that there are multiple source files, but the mapped locations aren't correct, and style.scss is never pointed to.

Again, Edge and Webstorm work perfectly. Chrome and Firefox have the same issue.

If you compile it with Sass directly, rather than via Gulp, is the problem the same? — cimmanon, Dec 03 '15 at 22:11
The output is a little different, but it did work that way. So that's a start; I just need to work out what the breaking difference is and then why. Good suggestion. — Kelsie, Dec 03 '15 at 22:40
@cimmanon: I changed the gulp-sourcemaps settings to match the raw sass output better and the same issue occurred. The only real difference remaining was the actual mappings. I then copied the base64 encoded mappings from the working sass output in to the not-working gulp-sourcemaps output. This worked. So the issue boils down to the actual encoded mappings. — Kelsie, Dec 03 '15 at 23:50
Additionally, I just reverted my gulp configuration changes so that the output is back in the format I want it to be in (not as closely matching the raw sass output), and then I again copy/pasted the base64 encoded mappings in to the output to replace the gulp generated encoded mappings, and it worked. — Kelsie, Dec 03 '15 at 23:53
Okay, I did another test where I directly used `node-sass` from within another task, and the output worked. So the issue seems to likely be in the `gulp-sass` code. — Kelsie, Dec 04 '15 at 01:24
I hooked up a debugger to the `gulp-sass` code and verified that the direct sourcemap output from `node-sass` from within `gulp-sass` works correctly. `vinyl-sourcemaps-apply` is definitely changing the sourcemap; it is reordering the `sources` array and there are a few differences in the mappings that look dubious. Further debugging required... — Kelsie, Dec 05 '15 at 01:55

score 0 · Accepted Answer · answered Dec 27 '15 at 19:33

I never did get around to debugging the actual sourcemap merge that I identified as buggy.

At the same time as I was trying to debug the merge, I submitted an issue to the gulp-sourcemaps project explaining that the problems with merging could be circumvented if the new sourcemap could overwrite rather than be merged. Obviously this is a workaround and not a fix, but it would get the job done.

The maintainer of the vinyl-sourcemaps-apply project made a change that causes a new sourcemap to overwrite when the existing source map has no mappings:

https://github.com/floridoo/vinyl-sourcemaps-apply/commit/30320c97c112f44ccba02dd73ce5bed1ad4361de

While this is not a 100% perfect solution, it is pragmatic and solves my immediate issue. The faulty merge is still an issue, but not one I have to deal with right now because my problem is solved by this workaround.

If you run in to a related issue and you legitimately do need to merge sourcemaps, the issue seems likely to be within the https://github.com/mozilla/source-map/ project.

Why doesn't chrome understand my scss source map?

1 Answers1