Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to (bundled) npm 8 or newer #61

Open
1 task done
DeeDeeG opened this issue Mar 20, 2023 · 1 comment
Open
1 task done

Migrate to (bundled) npm 8 or newer #61

DeeDeeG opened this issue Mar 20, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@DeeDeeG
Copy link
Member

DeeDeeG commented Mar 20, 2023

Have you checked for existing feature requests?

  • Completed

Summary

Switching to (bundled) npm 8 or newer in apm.

My first plan would be to ask the author of atom-community/apm#123 if it is okay to use their implementation at this repo. We can then verify whether it "just works" at that point, or needs more work for successful integration of newer npm into ppm.

What benefits does this feature provide?

Newer npm brings newer node-gyp.

Newer npm should be much faster than npm 6.

Allegedly, but I think in my personal use I have in fact seen it to be faster.

Newer npm will be supported further into the future.

In summary: Node 14 has npm 6. Node 16 has npm 8. Node 18 has npm 9.

Node 14 support ends 30 April, which is soon. We want to be on something newer for longer support.

Support timeline for various npm versions

See NodeJS support timeline, that's what most of this is based off of: https://github.com/nodejs/release#release-schedule


Note: Most of the biggest churn and breaking changes happened in npm 7, if I recall correctly / in my subjective recollection.

This was around the time GitHub acquired npm (!), and they (in my subjective opinion), went though a bit of a "move fast, break things" phase. They technically haven't stopped doing the "moving fast" part, I really wish they would focus more on testing changes with the ecosystem, but that is my bias as an end-user-testing-focused contributor to open source projects that apparently use some of npm's most obscure (and so least well preserved) features and quirks. It's just that many of their biggest ideas for "breakin' stuff" got expressed into code by the time npm 7.x was done, and so once we get over that hurdle of getting "somewhere past npm 7", npm 8 and 9 should hopefully be relatively somewhat smoother.


Any alternatives?

Alternatives are to stay on an unsupported npm version (npm 6)...

Which I prefer not to do long-term, so why not get out ahead of the (semi-official unofficial) EOL of npm 6?

Other examples:

No response

@DeeDeeG DeeDeeG added the enhancement New feature or request label Mar 20, 2023
@DeeDeeG
Copy link
Member Author

DeeDeeG commented Mar 20, 2023

Hello @bongnv, I saw your pull request atom-community/apm#123 over at atom-community/atom repostory.

Do you mind if I try that out for the Pulsar fork's ppm repository? Would you be interested in re-submitting the same changes as that PR but against this repository? Or would you mind if I post the commits (possibly rebased and with any other changes we find out might be needed) here as a new Pull Request?

Edit to clarify: I would ensure the original commit author metadata was intact so you would be credited for the contribution.

I appreciate the work you did before showing a way to get apm working with newer npm, so I wanted to see if ppm (an apm fork) could pick up where you left off rather than re-doing the same work you've already accomplished?

Thank you for considering.

Best Regards,
- DeeDeeG

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant