if (typeof fetch === "function") misidentifies node environment

[sprockow]

I am currently working building a node endpoint that accepts a minified stack trace from a client, and then uses this library to find the originating line in the un-minified source using a shared copy of the sourcemap.

The problem I'm running into is that the library uses "fetch" feature detection to determine whether the current environment is a browser or node environment.

if (typeof fetch === "function") {

and then conditionally exports a module in the read-wasm file: https://github.com/mozilla/source-map/blob/master/lib/read-wasm.js#L1

The node environment I'm developing within has been configured to use a isomorphic fetch polyfill, so this assumption has caused my node environment to incorrectly use the browser behavior and immediately throw the error:

You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer

I understand that my environment might be a bit different than most, but I'd like to challenge whether making assumptions like this is the correct way of browser vs. node detection. I came across a clever
solution described within this stackoverflow question, https://stackoverflow.com/questions/17575790/environment-detection-node-js-or-browser , where you can look up the default top-level function scope of the environment (window vs global). By looking at the default top level scope, this solution will even handle the case where window has been mocked out by a library like jsdom.

I've implemented this in a fork, and it seems to have fixed my problem. Wondering whether this is something you would be open to considering.

Also, if you otherwise think I've done something else completely wrong, please let me know. :)

[tromey]

I've implemented this in a fork, and it seems to have fixed my problem. Wondering whether this is something you would be open to considering.

It seems reasonable to me.

[sprockow]

Ok, let me put together a pull request and I'll send this over for review.

[sprockow]

Finally got around to doing this. Submitted #350 as a possible solution to this problem.

[tromey]

Fixed by #350.

[theKashey]

This issue is not solved or closed while fixed only in the beta version.

[loganfsmyth]

@theKashey I don't know when we'll be doing further releases, but there should be no problem using the beta release if it's a feature that is important for your usecase.

[theKashey]

Unfortunately some people (or their security department) could not afford beta releases. But if beta.0 is actually stable - could you publish it as, for example, next tag?

[karlhorky]

I'm also uncomfortable with using a beta version, given that it's been a year since the beta version has been released (will there ever be an 0.8.0 version with this same code?).

There is also the points that @Rich-Harris made in #400, which seem to be good reasons not to use the approach used in the beta.

This issue creates errors of non-insignificant complexity that can be difficult or impossible to debug, based on your skill level:

developit/unfetch#122

Of course, workarounds exist:

• switch to cross-fetch (eg. fix(server) isomorphic-unfetch with cross-fetch emcasa/react-starter#12)
• OR patch around it for your use case (eg. fix(gatsby): fix hot-reloading for hooks (patch hmr) gatsbyjs/gatsby#13713)

...but it seems like this should be fixed here in a non-beta version of source-map.

@loganfsmyth @fitzgen @tromey Would the team be open for considering another approach and releasing a non-beta 0.8.0 version?

cc @kunstloch