sprockets 4 makes Chrome browser identification of SCSS css lines _worse_

[jrochkind]

I don't myself understand what's going on, it clearly has something to do with source maps, but may also have to do with other sprockets changes.

But I can describe a simple reproduction case to demonstrate the developer inconvenience (can provide a sample app if it's helpful).

Setup

Let's say I have an app/assets/stylesheets/application.scss (note scss) that consists of one line:

`@import 'additional/additional`

Then that's importing a file at app/assets/stylesheets/additional/additional.scss that consists of one line for the purpose of demonstration, body { background: blue; }

Debugging in Chrome Inspector, Sprockets 3

I have launched my app in Rails dev mode. In Sprockets 3, if I "inspect" the "body" tag, and look at this in the inspector:

Now I click on that link to application...s?body, wanting to see where the body background blue decleration is, and I see:

It is showing me the actual CSS generated, and in a comment it's even telling me what .scss source file it came from at what line number. OK, great, not perfect, but enough for me to debug my CSS.

Debugging in Chrome inspector, sprockets 4

We'd think the addition of source maps in sprockets 4 might improve things. However, it is in fact harder for me to figure out where CSS is coming from.

With the same app with sprockets 4, still launching in dev mode, I "inspect" the body tag again, and see a similar thing:

I click on the application...rce link to find out more about where the CSS is coming from, and see:

It's just showing me the line @import "additional/additional". OK, I know what scss file it's coming from, but I can't actually see the CSS, and I don't even have a line number. I am not sure how to figure out what part of the SCSS source file is delivering this decleration.

Sprockets 4 is making it harder for me to debug my CSS, not easier. This is a very simple reproduction to demonstrate the issue, but in more complciated source (where you can have @import's that themselves have @import's, and sprockets 4 only takes me to the top first @import), it can be even worse.

Workarounds?

I don't really understand what's going on. Clearly source maps have something to do with it -- a source map feature that doesn't handle SCSS very well, apparently.

Is there a way to disable source maps in sprockets 4, possibly just for CSS and not for JS? I am not sure if that will restore the sprockets 3 debugging behavior I'm used to, but it seems worth a try -- but I can't figure out if there's a way to tell sprockets not to do source maps.

Alternately, I'm not sure if there's something I'm doing wrong, or something I can do to make source maps work better to actually give me a better debugging experience. If I can't do something to change the sprockets 4 debugging experience I am seeing, I am going to probably downgrade back to sprockets 3. I am finding it impossible to develop CSS the ways I am used to.

[jrochkind]

OK, I think the problem is that sprockets CSS sourcemaps feature isn't doing the right thing with sass/scss. Googling for examples of scss source maps,

It's unclear to me what other tools that handle SASS and sourcemaps do. Googling, I can find people complaining about this same problem with other tools, sourcemaps, and SASS @import.

Ah, here's an issue on another tool where the maintainers say they fixed it, and closed the issue. So other analagous tools for may have encountered this problem, and found solutions to it.

In the meantime, one workaround is you can tell Chrome not to use CSS sourcemaps. Chrome Developer Tools settings, under "Sources" section, uncheck "enable CSS source maps". After that, inspector behavior is the same as it was under sprockets 3 -- I can debug my CSS again!

[GCorbel]

I created this ticket about the same issue on sassc-rails : sass/sassc-rails#161.

It works if you set :

config.sass.inline_source_maps = true
config.sass.quit = false
config.assets.debug = true

And replace https://github.com/sass/sassc-rails/blob/v2.1.2/lib/sassc/rails/railtie.rb#L57 (in a fork or a monkey patch for example) by :

env.register_transformer 'text/scss', 'text/css', Sprockets::ScsscProcessor.new(importer: SassC::Rails::Importer, sass_config: Rails.application.config.sass)

[jrochkind]

Huh. I can't believe you got it to work!

Is there a PR to... something? sassc-rails? That would make the patch not necessary? (I don't know if there's any good way to monkey-patch that in, I think you have to fork? So some change seems required...)

Should the defaults be different somehow?

This is very difficult to figure out.

I am not sure this whole ecosystem currently has much maintainers unfortunately. :(

[GCorbel]

I didn't create a fork yet. I'm not sure about all consequences of my change and this is very complex.

I agree about lack of maintenance. It's probably because people use more and more Webpack.

[GCorbel]

@jrochkind I finally created a PR : https://github.com/sass/sassc-rails/pull/162/files. Let me know if it works in your case.

[jrochkind]

@GCorbel

I created a simple test app to test it... your branch in your PR (at 36d94ab59027) does seem to fix things for me!

(Note well, I did need to rm -rf tmp/cache to clear assets cache to get the fix; at first I thought it was having no effect when I neglected to do that).

Tested with my real app, not just a test app -- yep, it's working!

I am finally getting usable source maps for SCSS, wow!

No special configuration was required, my test app does have config.assets.debug = true in config/development.rb per rails generation, but I did not need to add config.sass.quit or config.sass.inline_source_maps directives -- with whatever are the defaults there from your branch.

(not sure why I didn't need to config.sass.inline_source_maps = true to get source maps, the sassc-rails readme implies that should not be the default but maybe it is? setting config.sass.inline_source_maps = false seems to have no effect at all, the SASS source maps are still working? Very confused what this config does, if anything).

Things I still wonder:

1. Is there some way to tell sprockets not to use source maps at all for CSS? Cause with sprockets 4 and sassc-rails 2.1.2 -- the source maps are unusable, I have to configure Chrome to not use CSS source maps at all. It would be nice to be able to tell sprockets not to use them. But if your PR gets in, will no longer be as necessary.

2. I don't understand why this isn't being considered a bigger deal by maintainrs/the community. Don't most Rails developers use SCSS? It's included by default in a new Rails app. Along with sprockets 4. I am mystified how anyone is managing to debug CSS in Rails at all these days, that this issue is being ignored makes sprockets seem like abandonware to me, or makes me wonder if nobody else is using sprockets 4, or what!

[GCorbel]

config.sass.inline_source_maps = true is used to have the source map inline and not in a separated file. config.assets.debug have to be false to make this working. With this option, you can have a source map on production too which is not possible with the current version of sprockets with other files.

Is there some way to tell sprockets not to use source maps at all for CSS? Cause with sprockets 4 and sassc-rails 2.1.2 -- the source maps are unusable, I have to configure Chrome to not use CSS source maps at all. It would be nice to be able to tell sprockets not to use them. But if your PR gets in, will no longer be as necessary.

config.assets.debug = false should be enough. It disables the source map for JS too but I see no other way.

I don't understand why this isn't being considered a bigger deal by maintainrs/the community. Don't most Rails developers use SCSS? It's included by default in a new Rails app. Along with sprockets 4. I am mystified how anyone is managing to debug CSS in Rails at all these days, that this issue is being ignored makes sprockets seem like abandonware to me, or makes me wonder if nobody else is using sprockets 4, or what!

Meh... as I said earlier, I think using Webpack is the recommended way now. Another issue is there is no way to generate source maps in production.

[jrochkind]

Meh... as I said earlier, I think using Webpack is the recommended way now.

So, the Rails docs are not, as far as I'm aware, able to answer this question at all. They still document sprockets for JS and CSS in most places, with a tiny bit of new docs of Webpack, mostly only for JS.

But last I have seen comments from DHH, he considered webpack(er) recommended for JS, but Sprockets still the preferred solution for (S)CSS. See https://rossta.net/blog/why-does-rails-install-both-webpacker-and-sprockets.html

But yeah, I'm not sure how you would determine which was the "recommended way" really. I don't see anything in Rails docs saying either way. Rails generators will still create scss in ./app/assets/stylesheets, and most tutorials (including Rails Guides) will still have you using them. But maybe few are still using sprockets at all, for JS or (S)CSS anymore? Hard to say.

Also unclear how much maintenance sprockets is getting in any case, right? This issue makes SCSS pretty impossible to debug in Chrome dev tools (without disabling source maps in chrome), but there has been no maintainer action on it... not sure if that means there is very little maintainance going on, or what.

If spockets were still being maintained, I'd suggest there ought to be config to disable source maps specifically, and specifically for either CSS or JS (not alwasy both), without turning off debug mode. As you note, debug mode does all sorts of different things that you might want with or without source maps.

[camilova]

I upgrade my rails app to 6.1 and had the same problem. My sourcemaps on Google DevTools were .coffe files, of course I could not debug them and It was impossible to find a solution after hours of searchs.

I ended up downgrading sprockets to version 3.7.2 and all is working fine again.