node_modules/@cspotcode/source-map-support/browser-source-map-support.js does not match any file.

[samal-rasmussen]

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.

[KrakenTyio]

i get same issue, on upgrading project to angular 12 and using @angular-builders/custom-webpack
main diferent is angular start working with webpack 5 but dont know where is issue

just-jeb/angular-builders#1046

[pe8ter]

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]

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-support ends up unexpectedly importing this instead of the old source-map-support package when you run under ts-node.

[pe8ter]

There's a conversation about this issue, and a new item filed to discuss changes to the matter.

[cspotcode]

@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]

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]

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]

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]

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]

@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:

• Upgrade Browserify to the latest version to support modern JavaScript syntax.
• Add Acorn as a dev dependency. One of the inner dependencies needs it, but I'm not sure why it wasn't automatically installed. Perhaps it's listed as a peer dependency and I missed it.
• Disable minification. Otherwise, the minified file is nearly empty.

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 provides module.require but 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]

@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-L660

[cspotcode]

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 to require('module') on node.

[pe8ter]

@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 the fs module. I also have no idea why my Karma tests have anything to do with Wasm, but my tests are breaking here anyway.

[cspotcode]

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]

Okay. I made this PR. Conversation can move there.

[elliottregan]

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.