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: https://github.com/webpack/webpack/issues/5767#issuecomment-336885530
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: https://github.com/webpack/webpack/issues/5767
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?
@MagicDuck feel free to PR
@MagicDuck friendly ping, any ideas how we can solve this?
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....
@MagicDuck Maybe you can create minimum reproducible test repo and README where describe what you have and what you expected?
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 馃槯
@MagicDuck What is want here, css-loader should in webpack namespace?
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:
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,
@MagicDuck hm, hard to understand without examples :disappointed:
@evilebottnawi If you reference the screenshot in the issue description above, I want the actual css source for foo.css to go under webpack://(sap.orca-sample-plugin)/src/foo.css instead of C:/code/sap-webpack-extensions... when output.devtoolNamespace="sap.sample-orca-plugin". Atm we actually see the cruft from style-loader under that path, which is not very useful.
@MagicDuck thanks looks like a bug, we need fix it
Related problem: loader doesn't support devtoolModuleFilenameTemplate and other devtool option in output option, we should fix it
Any updates on this?
It would be really cool to edit styles here:

and get them updated in source css / scss files.
I've tried playing with this for some time today, but even when I modify the plugin's output to have full file:// url
// Module
exports.push([module.i, "body h1 {\n background: red;\n color: black;\n font-size: 215px;\n}\n", "", {
"version": 3,
"sources": ["file:///Users/undsoft/htdocs/qt/test2/test.css"],
"names": [],
"mappings": "AAAA;EACE,eAAe;EACf,YAAY;EACZ,gBAAgB;AAClB",
"file": "test.css",
"sourcesContent": ["body h1 {\n background: red;\n color: black;\n font-size: 215px;\n}\n"]
}]);
Chrome still doesn't want to save it correctly.
Relevant issue: https://github.com/webpack/webpack/issues/6400
@undsoft https://github.com/webpack-contrib/css-loader/issues/717#issuecomment-471577500
@evilebottnawi
This won't work in the way I'm describing.
Editing from Sources tab will work and will correctly save to the original source file, but you need to manually go to Sources tab every time you want to make a change. To me this is marginally better than switching to an IDE.
What will not work is editing styles directly from the Elements tab as in my screenshot.
Add tests for devtool*
An example of the broken repository - https://github.com/alexhisen/mobx-forms-demo
Roadmap:
devtools value in a config (webpack keep true/false in the loaderContext.sourceMap option)context (from configuration) and uses webpack:// prefix (maybe be unique prefix to avoid rewritten existing source maps), like do it webpacksourceRoot should be emptyNeed to solve:
[contenthash] is unstable with mini-css-extract-plugin on webpack@4urls() break source maps mappingMost of issues are solved https://github.com/webpack-contrib/css-loader/issues/622#issuecomment-609818169, I want to do release and get feedback