Scoped package name bleeding into source map file association
After the package had a scope added, breakpoints don't work anymore.
The related files are written in typescript, and bundled via ts-loader from webpack. They are then served by a very basic webserver, and debugged via pwa-chrome.
What happens is, when a scope is added to the package, the package name somehow bleeds into the file path of the source maps. With a package.json name of "@scopename/packagename", the path for the source file suddenly becomes:
C:\some\parent\folders\packageRootFolder\packagename\some\child\folders\sourcefile.ts
this shouldn't be here -----------^^^^^^^^^^^
Luckily i noticed the change in file paths, otherwise i'd probably have sleepless nights and headaches for days over this one. I found, that i could open chrome's devtools, select the source file there, and setting breakpoints in it would work. If a breakpoint caught, vscode would open another tab with the source file, and break there. Hovering over the original file from disk, and the now duplicated source file, the difference in path became apparent.
Simply removing the scope from package.json solves the issue, and breakpoints work again.
I've added the yarnpkg tag (yarn 2 'berry', with pnp), because package.json is involved, for reasons i can't comprehend, so the related package manager may be useful information. Tbh i have no clue, which part is doing this, and why package.json is touched at all in this.
Why is this happening, and how can i fix it?
PS: whatever it is, it doesn't like slashes in the package name. I temporarily hacked in an invalid package name containing multiple slashes, and the part after the first slash just gets put into the path. Here is a sample of what this looks like, in the file, then chrome-devtools, then hovering over the file that opens when breaking from chrome-devtools:
It's likely either me making a very stupid mistake somewhere, or one link in the chain of source-map creators/transformers/consumers having a bug, or some misunderstanding.
Currently, i am trying to isolate the issue, and so far, typescript/ts-loader could be completely removed, and the issue prevails. Going to try in a standard setup with npm again, and if it still happens, both open an issue on webpack, and be confused, how this never got noticed before.
Source maps have a namespace, which can be set explicitly with a webpack configuration, e.g. output.devtoolNamespace = 'web', fixing the problem.