better working with source maps

[MagicDuck]

Do you want to request a feature or report a bug?
bug/feature

What is the current behavior?

The css-loader doesn't put it's stuff under webpack:// as far as I can see: https://github.com/webpack-contrib/css-loader/blob/master/lib/loader.js#L117

(Ignore some of the weird absolute paths under webpack://, It's cause my package.json is pointing to a local package)

Also, if you are loading a couple of libraries built with webpack which happen to have the same path for a css file (ex: .../src/mystyles.css), you will get sourcemap collision.

If the current behavior is a bug, please provide the steps to reproduce.
any build using the css-loader would do.

What is the expected behavior?
css-loader should be able to be configured to specify the file template.
This is @sokra 's opinion on the issue here: webpack/webpack#5767 (comment)

If this is a feature request, what is motivation or use case for changing the behavior?
We are building libraries with webpack which we load at runtime in our main app. We want to be able to easily debug issues in development.

Please mention other relevant information such as your webpack version, Node.js version and Operating System.

Associated issue on the webpack side: webpack/webpack#5767

[MagicDuck]

Also wanted to mention that I find it kind of weird that when the dev searches in the devtool, one of the matches for "foo.css" is actually the code produced by the style-loader (and the other by the css-loader). The regular dev shouldn't care about those. Is there a way to turn those off?

[alexander-akait]

@MagicDuck feel free to PR

[alexander-akait]

@MagicDuck friendly ping, any ideas how we can solve this?

[MagicDuck]

Wasn't there a plan to have special chunk templates to generate "css chunks"? Not sure what happened with that, but I am assuming that would make css loader obsolete...

In any case, if we still need to fix css-loader, my best guess for what needs to happen is to add a new option to the loader for sourcemap template path that gets emitted. It should have a smart defaul, defaulting to something using the library name, like I did for the js side in the associated issue mentioned above. We should also turn off or filter sourcemapping for style loader if possible to avoid confusion.

Unfortunately atm I am too swamped to do a PR....

[alexander-akait]

@MagicDuck Maybe you can create minimum reproducible test repo and README where describe what you have and what you expected?

[MagicDuck]

I thought the bug description above is pretty simple and explicit. Anyways, i would but like I said I don't have the time at the moment 😧

[alexander-akait]

@MagicDuck What is want here, css-loader should in webpack namespace?

[MagicDuck]

So imagine you are a dev and are working on an app where some of the consumed libraries have their own css and are in turn built with webpack. When you open the dev tool, you:

1. Want searching for a css file from a particular lib to be straightforward and make sense. So nested under webpack namespace but with the twist that the lib name is part of the path as in sourcemap collision when building as a library webpack/webpack#5767
2. The inclusion of the lib name as part of the paths prevents collisions in sourcemap when multiple libraries define a css file with the same name.

Of course if you are not building a lib, the lib name should not be part of the path, but path should still be in webpack namespace,

[alexander-akait]

@MagicDuck hm, hard to understand without examples 😞