Repository navigation
node_modules/@cspotcode/source-map-support/browser-source-map-support.js does not match any file. #30
Description
I suddenly started getting these errors after updating the packages in my project:
node_modules/@cspotcode/source-map-support/browser-source-map-support.js does not match any file.
...
ReferenceError: sourceMapSupport is not defined
at node_modules/karma-source-map-support/lib/client.js:1:1
I went into node_modules/karma-source-map-support/lib/index.js and added console.log('smsPath ' + smsPath); and ran my tests again it printed out smsPath <snip>node_modules/@cspotcode/source-map-support. I then went into my lock file and saw that ts-node was depending on @cspotcode/source-map-support. I then realized that I was running karma under ts-node using ts-node node_modules/karma/bin/karma start karma.conf.js. I changed this to node node_modules/karma/bin/karma start karma.conf.js and now it prints out smsPath <snip>node_modules/source-map-support and I can run my tests again without error.
@cspotcode/source-map-support is a rather new package, so it makes sense that this just started recently. But it means that the import code in karma-source-map-support needs to be made more robust in order to account for both the @cspotcode/source-map-support and the source-map-support packages existing now.
Activity
KrakenTyio commentedon Oct 26, 2021
i get same issue, on upgrading project to angular 12 and using
@angular-builders/custom-webpackmain diferent is angular start working with webpack 5 but dont know where is issue
just-jeb/angular-builders#1046
pe8ter commentedon Oct 27, 2021
My situation is slightly different but with the same ReferenceError. I see the error because I wrote my karma config in TypeScript, which means karma uses ts-node under the hood to compile the file. If I re-write my config in plain JavaScript, karma skips loading ts-node and there's no error.
This began with ts-node version 10.3.0.
samal-rasmussen commentedon Oct 27, 2021
The problem is as I explained that the new ts-node makes use of this new package: https://www.npmjs.com/package/@cspotcode/source-map-support
And that
karma-source-map-supportends up unexpectedly importing this instead of the old source-map-support package when you run under ts-node.[-]node_modules\@cspotcode\source-map-support\browser-source-map-support.js does not match any file.[/-][+]node_modules/@cspotcode/source-map-support/browser-source-map-support.js does not match any file.[/+]pe8ter commentedon Oct 27, 2021
There's a conversation about this issue, and a new item filed to discuss changes to the matter.
cspotcode commentedon Oct 29, 2021
@cspotcode/source-map-support does not include
browser-source-map-support.js. What if we started including that file again? Would that also solve the issue?We didn't want to do
require()redirection, but it was a necessary hack in order to fully replace the prior source-map-support package. This is necessary because it needs to be a global singleton; there cannot be two of them. They haven't implemented evanw/node-source-map-support#209, but we have: cspotcode/node-source-map-support#26 So it's ok if you have multiple copies of @cspotcode/source-map-support, but if you try to use source-map-support, it'll conflict and thus needs to be redirected to us.If shipping the
browser-file sounds like a good idea, I say we give it a shot.https://unpkg.com/browse/@cspotcode/source-map-support@0.7.0/
https://unpkg.com/browse/source-map-support@0.5.20/
pe8ter commentedon Oct 29, 2021
That should work in this case. Do you think it would be more work to produce this new file or add a new config option to ts-node to disable replacing source-map-support imports?
cspotcode commentedon Oct 29, 2021
Off-hand I'm not sure, because I don't remember where this browser file comes from. Is it built using rollup or browserify? I don't remember. I bet someone could find out by checking the source at https://github.com/evanw/node-source-map-support/
Adding a ts-node config option would be useful for multiple reasons, not solely for this. The other tickets I linked in TypeStrong/ts-node#1533 are not entirely identical features, but they would share code internally.
pe8ter commentedon Oct 29, 2021
source-map-support uses Browserify to produce the browser version of their library, then it uses the online Google Closure Compiler for minification.
So is the intent to re-package the existing @cspotcode/source-map-support source into a 2nd file called browser-source-map-support.js?
cspotcode commentedon Oct 29, 2021
Yes, that's the idea. If I removed anything necessary for the browser build from my fork, then someone creates a PR that re-adds it, gets the build running, and gets the browser tests running.
Then we can publish a new release.
pe8ter commentedon Oct 31, 2021
@cspotcode I'm giving this a shot but I'm having trouble enough that I don't really know how to proceed.
In my hacky attempt, these are the steps I took to get the bundle created again without build errors:
I added the built file to my own project, but I'm getting
TypeError: mod.require is not a function, which comes from this call point. Node.js providesmodule.requirebut it looks like Browserify does not define this function in the code it builds for the browser. I would expect it to throw an exception on Node.js functions that it cannot fill in for you, but apparently that is not the case.cspotcode commentedon Oct 31, 2021
@pe8ter thanks, sounds like you've made great progress so far.
It looks like, when the upstream source-map-support calls
dynamicRequire, it's wrapped in a!isInBrowser()check. I bet we can do the same here.We can also add a
!isInBrowserCheck()to this conditional, because it's another node-only feature: https://github.com/cspotcode/node-source-map-support/blob/817f84b2820e7395a274379cf80e79930e15d3b2/source-map-support.js#L652-L660cspotcode commentedon Oct 31, 2021
Whoops, forgot to add a link to the upstream code I was looking at:
https://github.com/evanw/node-source-map-support/blob/master/source-map-support.js#L558-L561
We can do something like
var Module = isInBrowser() ? undefined : dynamicRequire(module, 'module');so we only attempt torequire('module')on node.pe8ter commentedon Nov 2, 2021
@cspotcode Still plugging away. I found a few more spots in your fork that could probably use the
!isInBrowser()check. The next major issue that I found is that there is a sibling package @cspotcode/source-map-consumer that has some issues as well. You can see here that there's no browser check for accessing thefsmodule. I also have no idea why my Karma tests have anything to do with Wasm, but my tests are breaking here anyway.cspotcode commentedon Nov 2, 2021
Should we move discussion to a pull request on cspotcode/node-source-map-support? That way I can comment on specific bits of code as you push them.
The Wasm stuff is a more performant parser of sourcemaps. I'll put some comments on a PR once you create it. We might be able to pragmatically avoid the wasm parser entirely for the browser.
pe8ter commentedon Nov 2, 2021
Okay. I made this PR. Conversation can move there.
elliottregan commentedon Dec 1, 2021
That PR is closed. There's a lot of background info I'm not up to date on, but I'm happy to help where I can.