sourcemap collision when building as a library #5767

MagicDuck · 2017-10-06T00:40:45Z

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

What is the current behavior?
This happens when you have multiple webpack builds that integrate at runtime. For instance, I have a couple of projects that are built as webpack libraries (libraryTarget: "jsonp"). I use those libraries in a 3rd project. When I try to debug, I can see the sourcemaps for the libraries code in the devtool, but if you happen to have a file with the the same path in both libraries, for example:
"webpack:///src/index.js"
Then you basically just see the one for last loaded library...

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
We should have a way namespace those paths. Would be nice if you could change only the webpack:/// prefix independent on the devtool being used. Then we could switch it to something like: webpack (<library name>):///
I am guessing there should be some config option, a function, which is applied on the template as a last thing before usage. The reason for not using output.devtoolModuleFilenameTemplate is that there seem to be different defaults for different devtool settings...
If this is a feature request, what is motivation or use case for changing the behavior?
debugging webpack built lilbraries
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

The text was updated successfully, but these errors were encountered:

sokra · 2017-10-11T14:02:11Z

Are you thinking about adding the output.library name to the devtool prefix by default? This makes sense to me, so send a PR.

MagicDuck · 2017-10-12T01:30:39Z

@sokra yes, will try to do that. I do have some questions though:

In my case, the library name is too convoluted since we have designed a "plugin loading" mechanism,
where each plugin is a webpack lib. The library name is something like mynamespace['my.plugin.with.dots']. I would like to able to modify the devtool prefix with a function before usage. EvalDevToolModuleTemplatePlugin, EvalSourceMapDevToolModuleTemplatePlugin and SourceMapDevToolPlugin seem to have their own defaults that get overriden though WebpackOptionsApply. Is it ok to add the option of output.devtoolModuleFilenameTemplate being a function (function(defaultTemplate : string) -> string), in which case it gets applied late, after the defaults have been set, rather than early? Or what would you consider to be the best way to approach this?
What do you think the the base default be? Something like this: webpack:///([library])/[resourcePath]. This would also affect the current non-library case. We could make library="main" or something in that case so you would get webpack:///(main)/[resourcePath]. Would that be ok though? Or should we just change [resourcePath] to include the library name? I am not sure if that could break other stuff...
What do we do about css-loader? It doesn't seem to respect the output.devtoolModuleFilenameTemplate. When I look at my ".css files" under webpack://, they all contain the js produced by the style-loader, it's not the original css. I don't think this is useful for the regular dev.

sokra · 2017-10-12T07:29:51Z

We could add a options output.devtoolNamespace which defaults to the output.library when not specified. This way you can override it when a custom name is needed. Although __mynamespace__['my.plugin.with.dots'] will probably work too.
For the non-library build devtoolNamespace should be undefined, which will produce the same result as it does currently. With devtoolNamespace set to a value it produce the format you stated: webpack:///[namespace]/[resourcePath].... The [namespace] placeholder need to be added to the moduleFilenameTemplate option.
On long term this will be integrated into webpack, so this is not an important issue. On short term we can add the namespace option to the style-loader too to generate source-maps in the same namespace.

MagicDuck · 2017-10-13T23:26:30Z

@sokra thanks for the reply! Having output.devtoolNamespace option makes sense to me. For number 3, I guess I didn't really communicate that properly. The css-loader doesn't even 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)

michael-ciniawsky · 2017-10-14T10:23:28Z

@MagicDuck Feel free to open an Issue /PR at style-loader/css-loader in case any work is required there :)

MagicDuck · 2017-10-15T01:16:04Z

I can do that. Just wanted to get to get @sokra 's opinion since he has the context to give a wholistic approach to the solution rather than piecemeal everywhere.

sokra · 2017-10-16T13:25:05Z

In my opinion a prefix for the CSS Source Maps does make sense. Maybe we shouldn't merge it into webpack:// because it would conflict with the JS files. Maybe webpack-css:// make sense here. I need to be configurable, because some tools like create-react-app don't like the prefix and like to use absolute resource paths instead.

When loading multiple libraries built with webpack, you can run into collisions of the sourcemap file paths. For examle, both have "webpack:///src/index.js". This change addresses the problem by introducing a new output option `output.devtoolNamespace` which defaults to `output.library` when not specified. The defaults moduleFilenameTemplates in all the sourcemap plugins have been modified to start with: "webpack://[namespace]/...", where [namespace] will be replaced by the `output.devtoolNamespace`. Notice that there are only two slashes following "webpack:" now. This is to make it behave just as before when not building with a namespace. When building with a namespace you only get the two slashes, but from what I've seen the chrome dev tools only care about the first 2 slashes anyways. webpack#5767

When loading multiple libraries built with webpack, you can run into collisions of the sourcemap file paths. For examle, both have "webpack:///src/index.js". This change addresses the problem by introducing a new output option `output.devtoolNamespace` which defaults to `output.library` when not specified. The defaults moduleFilenameTemplates in all the sourcemap plugins have been modified to start with: "webpack://[namespace]/...", where [namespace] will be replaced by the `output.devtoolNamespace`. Notice that there are only two slashes following "webpack:" now. This is to make it behave just as before when not building with a namespace. When building with a namespace you only get the two slashes, but from what I've seen the chrome dev tools only care about the first 2 slashes anyways. Discussed with sokra here: webpack#5767

MagicDuck · 2017-10-17T23:57:34Z

PR here: #5844 :)

When loading multiple libraries built with webpack, you can run into collisions of the sourcemap file paths. For examle, both have "webpack:///src/index.js". This change addresses the problem by introducing a new output option `output.devtoolNamespace` which defaults to `output.library` when not specified. The defaults moduleFilenameTemplates in all the sourcemap plugins have been modified to start with: "webpack://[namespace]/...", where [namespace] will be replaced by the `output.devtoolNamespace`. Notice that there are only two slashes following "webpack:" now. This is to make it behave just as before when not building with a namespace. When building with a namespace you only get the two slashes, but from what I've seen the chrome dev tools only care about the first 2 slashes anyways. Discussed with sokra here: webpack#5767

MagicDuck · 2017-10-18T00:41:09Z

also filed issue on the css-loader side: webpack-contrib/css-loader#622

adrianromanko · 2018-03-05T17:28:20Z

@MagicDuck Thanks for adding this options. I'm waiting for your namespace PR request to go through.

MagicDuck · 2018-03-05T18:42:08Z

@adrianromanko my pleasure 😀. I looks it was merged a while ago. Its probably available in webpack 4.
This issue should probably be closed...

jazdw · 2018-06-18T20:09:01Z

Thanks for this, its useful when you build a library with multiple entry points. I use a library option like this library: '[name]' and without setting devtoolNamespace it shows up in the Chrome debugger as %5Bname%5D.

MagicDuck · 2018-06-20T04:53:23Z

@jazdw that sounds like a bug to me. You should file an issue I think. Closing this one.

airtonix · 2020-02-19T09:40:00Z

@jazdw Did you end up creating that ticket, also experiencing the same problem:

many entrypoints, many output bundles, each being a umd library with sourcemaps that all get called [name] in Chrome.

jazdw · 2020-02-19T10:13:14Z

@airtonix no I didn't sorry

MagicDuck mentioned this issue Oct 6, 2017

How to resolve file path from a webpack:/// URI #2395

Closed

MagicDuck mentioned this issue Oct 17, 2017

adding output.devtoolNamespace option #5844

Merged

MagicDuck mentioned this issue Oct 18, 2017

better working with source maps webpack-contrib/css-loader#622

Open

webpack-bot added the Send a PR label Feb 20, 2018

TheLarkInn added X5: work required (PR / Help Wanted) and removed X5: work required (PR / Help Wanted) labels Feb 21, 2018

MagicDuck closed this as completed Jun 20, 2018

alexander-akait mentioned this issue Apr 30, 2021

Add option to SourceMapDevToolPlugin to exclude webpack:// protocol #12583

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sourcemap collision when building as a library #5767

sourcemap collision when building as a library #5767

MagicDuck commented Oct 6, 2017 •

edited

sokra commented Oct 11, 2017

MagicDuck commented Oct 12, 2017

sokra commented Oct 12, 2017

MagicDuck commented Oct 13, 2017 •

edited

michael-ciniawsky commented Oct 14, 2017 •

edited

MagicDuck commented Oct 15, 2017

sokra commented Oct 16, 2017

MagicDuck commented Oct 17, 2017

MagicDuck commented Oct 18, 2017

adrianromanko commented Mar 5, 2018

MagicDuck commented Mar 5, 2018

jazdw commented Jun 18, 2018

MagicDuck commented Jun 20, 2018

airtonix commented Feb 19, 2020

jazdw commented Feb 19, 2020

sourcemap collision when building as a library #5767

sourcemap collision when building as a library #5767

Comments

MagicDuck commented Oct 6, 2017 • edited

sokra commented Oct 11, 2017

MagicDuck commented Oct 12, 2017

sokra commented Oct 12, 2017

MagicDuck commented Oct 13, 2017 • edited

michael-ciniawsky commented Oct 14, 2017 • edited

MagicDuck commented Oct 15, 2017

sokra commented Oct 16, 2017

MagicDuck commented Oct 17, 2017

MagicDuck commented Oct 18, 2017

adrianromanko commented Mar 5, 2018

MagicDuck commented Mar 5, 2018

jazdw commented Jun 18, 2018

MagicDuck commented Jun 20, 2018

airtonix commented Feb 19, 2020

jazdw commented Feb 19, 2020

MagicDuck commented Oct 6, 2017 •

edited

MagicDuck commented Oct 13, 2017 •

edited

michael-ciniawsky commented Oct 14, 2017 •

edited