if (typeof fetch === "function") misidentifies node environment #349
Comments
It seems reasonable to me. |
|
Ok, let me put together a pull request and I'll send this over for review. |
|
Finally got around to doing this. Submitted #350 as a possible solution to this problem. |
|
Fixed by #350. |
|
This issue is not solved or closed while fixed only in the beta version. |
|
@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. |
|
Unfortunately some people (or their security department) could not afford |
Firstly thanks very much for this excellent library.
# Problem
I am running a Nodejs app and am hitting the following error when using this library:
```
You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer
```
# Diagnosis
* A dependency of yours "source-map" detects the runtime (Nodejs vs browser) in a broken way. That library then throws an exception if some client-side-specific code is not run.
-*The "check" checks for the presence of a variable "fetch" and the reasonable thinking is that only browsers will have fetch. The issue is that in my case and in some others (see [here](mozilla/source-map#349)) 3rd party libraries can define a variable "fetch" which
# Tests
None
Firstly thanks very much for this excellent library.
I am running a Nodejs app and am hitting the following error when using this library:
```
You must provide the URL of lib/mappings.wasm by calling SourceMapConsumer.initialize({ 'lib/mappings.wasm': ... }) before using SourceMapConsumer
```
* A dependency of yours "source-map" detects the runtime (Nodejs vs browser) in a broken way. That library then throws an exception if some client-side-specific code is not run.
* The "check" checks for the presence of a variable "fetch" and the reasonable thinking is that only browsers will have fetch. The issue is that in my case and in some others (see [here](mozilla/source-map#349)) 3rd party libraries can define a variable "fetch" which triggers the described error.
None
|
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 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: Of course, workarounds exist:
...but it seems like this should be fixed here in a non-beta version of @loganfsmyth @fitzgen @tromey Would the team be open for considering another approach and releasing a non-beta cc @kunstloch |
|
This is also an issue with package dependencies, for example we use react-hot-loader which has source-map as a dependency. I had to use yarn's resolutions feature to force my package manager to make react-hot-loader use the beta version - an awkward solution considering we don't use yarn |
|
|
@theKashey I don't use that. Just using react-static |
`source-map` was incorrectly attempting to detect if we're in a browsers context by checking if `typeof fetch === 'function'` which in never versions of node if present. Because of this source-map was reqesting that we provide a WASM file. [read more here](mozilla/source-map#349) Bumping to 0.8.0-beta.0 fixes this. Also filters out any files in the sourcemap which don't have a file contents associated with it.
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:
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 (
windowvsglobal). By looking at the default top level scope, this solution will even handle the case wherewindowhas 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. :)
The text was updated successfully, but these errors were encountered: