Source map not created

[foxacid]

Hey, thanks for this nice setup!

Setting sourceMap: true in sass.js adds a sourceMappingURL to the CSS files but does not actually compile a source map. Any ideas?

[bnjmnrsh]

A quick scan through, it looks like parseSass doesn't handle the sourceMap flag.
However, Im thinking a new function parseMaps might be in order. It may not be totally DRY, but then could be called explicitly in the config.files.forEach() on line 72

Something like:

configs.files.forEach(function (file) {
    parseSass(file)
    if (configs.minify) {
        parseSass(file, true)
    }
    if (configs.sourceMap){
        parseMaps(file)
    }
})

If that looks like a good approach, I'll have a go at a PR.

[cferdinandi]

Yea that looks great!

[bnjmnrsh]

I notice that rollup.config.js also doesn't generate sourcemaps when passed the sourcemap: true, and I have a patch for this as well, which I can submit jointly in the same PR.

A question for @cferdinandi would be, would you like the default behavior to include source maps or not?

I generally agree with Chris Coyier's take on this topic, in that they don't impact performance or the end-user experience. As a boilerplate/project scaffold, to me it makes sense for quickly spooling up a new project if they were on by default - IMHO.

[foxacid]

Awesomesauce! FWIW I find sourcemaps to be invaluable tools for development and I generally deploy them to production sites, too...

[cferdinandi]

I'd personally prefer they not be the default, with an option to enable them.

[bnjmnrsh]

@foxacid @cferdinandi let me know if #12 behaves as expected.

[foxacid]

@bnjmnrsh Thanks a lot! It works flawlessly with expanded CSS files but seems broken for minified CSS, unfortunately...

[cferdinandi]

The minified CSS strips out all comments, which is likely where the issue stems from.

[foxacid]

Hmmm, the sourceMappingURL is added after minification so that's not it... (unless it's some other comment you mean)

[cferdinandi]

But the in-code comments it uses are stripped out, no?

[bnjmnrsh]

@foxacid Taking the project as is, if I adjust the stylesheet link to main.min.css in index.html and npm run serve the generated css looks like this:

/*! BuildToolsCookbook v2.0.0 | (c) 2021 Your Name | MIT License | http://github.com/cferdinandi/build-tools-boilerplate */
body{font-size:125%;margin:0 auto;max-width:42em;width:88%}input,textarea,select,button{font:inherit}

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

In this case, the sourcemap link is generated by sass, and we are piping in the license block after it does so, and everything here works as expected.

So currently I suspect two possible culprits:

• your SCSS is malformed in some way that is throwing a spanner in the works
• possibly the file write process has malformed the content based a previous build.

On that second point, I have seen a few instances where rather than fully replacing all the content of the file output, only half the data was written. I tossed it up as a fluke at the time.

I swear I have a point that Im trundling toward here! But if you wouldn't mind, double-check that your SCSS validates, and make sure when you run the build again, but that you first delete everything in dist/css/* and run npm run css and build it from scratch.

If you're still getting errors after those checks, could you provide a reduced test case of SCSS that I can use to see what's going on?

[foxacid]

@bnjmnrsh Thank you for bearing with me. Indeed the generated CSS and sourcemap URL look correct. I usually develop on Firefox but while writing this I quickly checked on Chrome and - lo and behold - the minified sourcemap works just fine!

Here are the Firefox screenshots I prepared a few minutes earlier using the sourcemaps branch from your forked repo - you can see how the minified CSS is not referencing _base.scss but instead the final CSS file:

[bnjmnrsh]

Just to double-check, I just discovered (as I don't always use FF for debugging) that sourcemaps are not enabled by default in FF dev tools (yes, even in FF Developer Edition!). Can you check they are enabled for you?
Once enabled everything worked just fine.

These photos are for Mac FF Developer Edition. PC may be slightly different.

[bnjmnrsh]

Hold the press . . . the URL in your snapshots shows you're loading the file directly, not using the development server, it should be HTTP://localhost:XXX/, not file:///Users/... This explains the warning about character encoding.

Please also make sure to cd into the directory holding the project and then run npm run server command and test the sourcemaps from the development server.

[foxacid]

I had the source maps option enabled.
Accessing the index file via the Browersync server does not make a difference.

FWIW I'm running FF 87.0 on macOS 10.14.6. I'm currently downloading the Developer Edition to see if that works...

[foxacid]

Same behaviour on Firefox Developer Edition 88.0b5. Sourcemaps for expanded CSS work like a charm, not so the minified version. Can you confirm that loading the minified main.min.css shows you the source SASS file _base.scss in the inspector?

[foxacid]

In any case this seems like a Firefox bug as it works flawlessly in Chromium based Browsers. So I guess the issue is good to be closed...?

[bnjmnrsh]

@foxacid, I've tested minified sourcempas on FF Dev Edition 88.05b, and FF 86.0 and I'm not able to reproduce this issue - all references to _base.scss are working as expected. Incidentally, I'm also on OSX 10.14.6.

A real head-scratcher, perhaps some sort of caching or permissions issue?

For comparison, for stand-alone source maps, here is what Im getting:

{"version":3,"sourceRoot":"","sources":["file:///Absolute/Path/To/Project/build-tool-boilerplate/src/scss/components/_base.scss"],"names":[],"mappings":"AAAA;AAAA;AAAA;AAIA;CACC;CACA;CACA;CACA;;;AAGD;AAAA;AAAA;AAAA;CAIC","file":"main.css"}

{"version":3,"sourceRoot":"","sources":["file:///Absolute/Path/To/Project/build-tool-boilerplate/src/scss/components/_base.scss"],"names":[],"mappings":"AAIA,KACC,eACA,cACA,eACA,UAGD,6BAIC","file":"main.min.css"}

Lastly, have you tested setting the configs: sourceMapEmbed: true?
This will inline the source map rather than use an external file.

[foxacid]

I found something!

Firefox will show the original SASS file in the Style Editor tab (provided the 'Show original sources' option is enabled), but not in the Inspector tab. This is strange because it does show the original source in the Inspector tab when using expanded CSS...

min-sourcemaps.mov

[bnjmnrsh]

Ahh, Im glad we got it figured out. I'll update the version of the readme in this PR to highlight this for FF users.

I've run into a separate issue that affects portability and will add comments, and push an update shortly.

[bnjmnrsh]

In ref to 539006f:

I've realised that the JavaScript implimtation of dart-sass, JavaScript API only generates absolute system paths for the sources array when using, render() or renderSync().

This means that the source maps this PR had generated were bound to the environment in which they were built (ie local vs production), resulting in source maps that look like this:

{"version":3,"sourceRoot":"","sources":["file:///Absolute/Path/To/Project/build-tool-boilerplate/src/scss/components/_base.scss"],"names":[],"mappings":"AAIA,KACC,eACA,cACA,eACA,UAGD,6BAIC","file":"main.min.css"}

It's unreasonable to force Devs to build in production for source maps to work there, and in many cases, the src directory may not even be pushed to production. Even if it were pushed, programmatically trying to calculate the relative paths ourselves and manipulate the generated source map as it was being written is overthinking things.

The Dart Sass CLI exposes a --source-map-urls flag accepting absolute or relative options, but these options are not provided in the JavaScript API. We do however have an option to embed the original source files into maps themselves with the sourceMapContents flag, with the following caution:

[Using sourceMapContents...] may produce very large source maps, but it guarantees that the source will be available on any computer no matter how the CSS is served.

Going this route wouldn't affect the end-user, as they wouldn't load maps (unless they open Devtools), but it will make it much easier to debug CSS in a production where the absolute paths generated locally are sure to be broken.

To prevent people accidentally pushing to production inflated CSS with both the source map and the source SASS embeded, I've removed the sourceMapEmbed option from configs.

[foxacid]

Good work @bnjmnrsh! Seems like you went down the sourcemaps rabbithole ;)

[bnjmnrsh]

@foxacid rabbit-hole indeed!

We've spent a lot of time looking at the Sass side of things, and on the JS side Rollup seems to be handling source maps without issue –– Chrome/FF/Safari are pointing to non-minified versions of files as expected.

@cferdinandi, based on these tests I believe this PR, feature-wise, is in a complete state. Is there anything you would like to see changed?