Open MagicDuck opened 6 years ago
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
@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
While it's certainly a little ugly, perhaps the url(...)
issue (which still exists) could be addressed by making sure the url(...)
length before / after is the same, by reserving some extra space in the generated CSS, and replacing it by empty spaces as needed after resolving the require?
So for example, the following:
background: url(___CSS_LOADER_URL___0___RESERVING_SPACE_FOR_SOURCE_MAPS___);
Would turn into (note how the semicolon position is the same before / after):
background: url("path/to/image.png") ;
it wouldn't be perfect, and it wouldn't work if the url(...)
expression is larger than the reserved space, but since those whitespace would be removed anyway by cssnano, it seems it could be a decent workaround.
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