SourceMaps in Windows do not display correctly

[andyfinch333]

Description

SCSS SourceMaps in any of the downloadable starter kits or in a fresh build of Gatsby, do not correctly show SCSS SourceMap references in the Web Inspector. In Firefox on Windows you see a Blob reference (Screenshot attached), In Chrome, you see an absolute path that repeats several times (screenshot attached), which while better as I can work out what file the code references, does not look great. I feel like a lot of people must have this issue as all the starter kits i've downloaded have this problem. This issue is present in Gatsby v1 and v2, it is not present in similar Static Generators such as Next.js, so I feel it's not an issue with Webpack.

The same build, when run on Linux, shows source map references correctly which leads me to believe this issue seems to be limited to Windows.

Steps to reproduce

1. Clone repository - https://github.com/ueno-llc/ueno-gatsby-starter
2. Follow instructions to install, launch gatsby develop.
3. Use web inspector to view sourcemap location

Works with any repository from Starter Library or fresh build of Gatsby.

Expected result

Ideally, you will see scss source maps are compiled correctly and display correctly in All Browsers pointing only to a file with extension.

Actual result

You see scss source maps are compiled but in Firefox inspector you see a Blob Reference.
You see scss source maps are compiled but in Chrome inspector you see an absolute path 3x.
You see scss source maps are compiled correctly and display correctly in Chrome on Linux.

Environment

Gatsby 2.1.23
Windows 10

Run gatsby info --clipboard in your project directory and paste the output here.

Command not recognized.

Screenshots

[pieh]

I did reproduce it locally, will investigate

[pieh]

This issue doesn't seem sass/scss specific - it also happen with vanilla css, so I this seems either css-loader or style-loader (or our configuration for them)

[pieh]

Seems like this is exactly this problem - webpack-contrib/postcss-loader#390

[andyfinch333]

Yeah I think you are right, Seems this issue has not been fixed yet, is the best way to remove postcss loader? However, I'm not finding it easy to see what the default Webpack config for Gatsby is to modify it.

[wardpeet]

It's not easy to remove it and it might break your site but you can find more info on how to replace your webpack config
https://www.gatsbyjs.org/docs/add-custom-webpack-config/

[pieh]

@andyfinch333 The problem is ... that css-loader is calling postcss in its internals ( https://github.com/webpack-contrib/css-loader/blob/v1.0.1/lib/processCss.js#L182-L192 ) this is exact spot where source maps are getting mangled - before that they are correct - but output of the postcss pipeline contains borked paths. So removing postcss won't solve this as css-loader on itself is doing that.

That being said - we are on css-loader@1 and there is version 2 released, just not sure if this is fixed and if there are any breaking changes that would cause troubles to existing sites.

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!