Allow Node.js-like runtimes to identify as Node.js as well. #2357
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, in order to only load dependencies which only work on Node.js and fail in non-Node.js environments, we introduced a check which did a string-comparison of `process.release.name` to see if it is was `node`. This was first introduced in 9c563fa as part of #2054, but has gone on to be useful for other purposes as well. Some Node.js forks such as NodeSource's N|Solid, which is a fork of Node.js which follows-up each Node.js release with a custom build that includes additional native addons but is otherwise the same, override this value with their own name. This means that N|Source returns `nsolid`, despite the fact that it is almost entirely the same as Node.js. Luckily, N|Solid leaves the base version of its Node.js in `process.versions.node` (and additionally adds its own `process.versions.nsolid`). By relaxing the string comparison on `process.release.name`, we should still be able to accurately detect the environment we want - which is "Close enough to Node.js!". Fixes #2356
abernix
referenced
this pull request
in apollographql/apollo-tooling
Mar 4, 2019
trevor-scheer
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
Mar 4, 2019
For more context, see: apollographql/apollo-server#2357
trevor-scheer
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
Mar 4, 2019
For more context, see: apollographql/apollo-server#2357
trevor-scheer
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
Mar 13, 2019
For more context, see: apollographql/apollo-server#2357
trevor-scheer
added a commit
to apollographql/apollo-tooling
that referenced
this pull request
Mar 13, 2019
For more context, see: apollographql/apollo-server#2357
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, in order to only load dependencies which only work on Node.js and fail in non-Node.js environments, we introduced a check which did a string-comparison of
process.release.nameto see if it is wasnode.This was first introduced in 9c563fa as part of #2054, but has gone on to be useful for other purposes as well.
Some Node.js forks such as NodeSource's N|Solid, which is a fork of Node.js which follows-up each Node.js release with a custom build that includes additional native addons but is otherwise the same, override this value with their own name. This means that N|Source returns
nsolid, despite the factthat it is almost entirely the same as Node.js.
Luckily, N|Solid leaves the base version of its Node.js in
process.versions.node(and additionally adds its ownprocess.versions.nsolid). By relaxing the string comparison onprocess.release.name, we should still be able to accurately detect the environment we want - which is "Close enough to Node.js!".Fixes #2356