Allow an env var to skip install.js for this package only #1311
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.
This will allow us (hopefully; I have no confirmation that skipping this step results in a successful build which doesn't fail at runtime -- see #1310) to disable this install script for this package only, something that none of the major node package managers allow (couldn't find a way in any of npm/yarn/pnpm to do this for only this package -- only globally disable scripts, when
find node_modules -name package.json | wc -l
is almost 7000 files, i'm not sure how i'm ever supposed to validate that "globally disallow lifecycle scripts" doesn't break anything).In any case, since this package claims to be "pure javascript", it should have an easy and explicit way to disable C++ modules, and actually be "pure" javascript.
But, again, I don't know if this even makes a difference. Our CI "forgot" to bundle binary modules, and this caused our production services to fail at run-time because it couldn't load this module. I'm fairly sure there is something else I need to do in this PR to disable this binary module, but I don't know what it is. To me, that means that if this script is disabled, this binary module won't appear in our codebase, and we'd get the same runtime exception thrown about not being able to load it as we did when our CI skipped adding it (because "don't copy it into the codebase" and "never generate it in the first place" SHOULD behave the same when "it doesn't exist", which is either "this is ok, i can live w/o this module" or "i fail at runtime b/c this module isn't there". For us, it is always the latter)