node 9.1.0 + patched npm (WIP / discuss) #20431
Closed
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.
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install <formula>
)?ToDo:
node@8
formulanode@6
andnode@4
the same way@ilovezfs This PR updates node to v9.1.0 and patches npm in a way, that the node 9 compatibility will survive self updates (by applying npm/npm@f24c1db and parts of npm/npm@4ca6958 (=isaacs/minizlib@a40d6ce)).
This work, because:
minizlib
version (1.0.3) every bundled in npm since its introduction innpm@5.4.0
(withnode-tar
) andminizlib
version bump from (1.0.3 to 1.0.4) but instead patching theminizlib@1.0.3
already bundled insidenpm@5.5.1
to be node9 compatible (and keep it as v1.0.3).You can test this by running multiple times
npm i -g npm
andnpm i -g npm@5.4.2
after installing this formula version without breaking npm.Note: While the minizlib patch (needed for node 9 compatibility) persists npm self upgrades, the also applied patch to suppress the incorrect incompatibility warnings does not persist self upgrades. Unfortunately you will notice a stupid runtime warning after the first self upgrade, telling you that your node 9 is to old for this npm version and you should install node 4+.
This happens when...
minizlib@1.0.3
,npm i -g npm
would update to 5.5.1 as of now): When downgrading tonpm@5.4.0-5.5.1
npm only tries to update/replace the packages that have changed between both versions. Because we've labeled ourminizlib
version as the plain old v1.0.3 (while in reality it's a patched version identically to what would be inminizlib@1.0.4
) npm doesn't touchesminizlib@1.0.3
at all during upgrades (to these versions) and just keeps our patched node9 compatible version installed (because npm thinks our already installed version would be the same as the one requested by the update).minizlib@1.0.4
): In this case npm will replace our patchedminizlib@1.0.3
with the realminizlib@1.0.4
(which is identical except metatdata) and npm will continue to work because we just installed a node 9 compatible npm version. At this point (when said version isnpm@latest
and not onlynpm@next
) we should upgrade or formula to said npm version anyway and remove the workaround from this PR. Note: Downgrading at this future point in time tonpm@5.4.0-5.5.1
will result in a broken npm, similar to how downgrading to early version of npm@2 or 1 have resulted in a broken npm since node 4+node-tar
, not usingminizlib
at all): In this case npm will remove our patchedminizlib
version, but because these version of npm are node 9 compatible, everything should work fine. Note: Upgrading from there again back tonpm@5.4.0-5.5.1
will result in a broken npm, which is unfortunate but as said above we have to life forever with the fact, that installingnpm@5.4.0-5.5.1
with node 9+ will break npm in the future similar to as installing a early version of npm@2 or 1 with node 4+ is breaking npm already as of now. Also downgrading npm to something prenpm@5.4.0
and the upgrading back again tonpm@5.4.0-5.5.1
shouldn't be a common use case (but maybe we should warn about it in the caveats?).