On 20/07/2021 20:51, Ryan Schmidt wrote: > An npm portgroup is a good idea if we ever want npm-based software to > (re-)appear in MacPorts. The lack of this is why I couldn't update my > coffee-script port for years and it was ultimately removed.
Before I started working on this, I noticed your very useful analysis on what an npm portgroup should provide: https://github.com/macports/macports-ports/pull/2997#pullrequestreview-174055005 Based around this, I've implemented the following as part of a "javascript-1.0" PG: - Support for the npm registry (livecheck, homepage, etc.) - More reproducible builds via --frozen-lockfile, --build-from-source and npm ci - nodejs/npm deps are sorted out to the best of my ability - Capability to switch to yarn However, I still need to do the following: - Fix the destroot when not using the npm registry (e.g. github instead) - Cargo-like fetch mechanism > Back when node and npm were new and backward-incompatible changes were frequent there was a great need to be able to specify which node and npm version to use. If that need continues to exist and you plan to build node and npm version selection into the npm portgroup, then I think it would be nearly unworkable not to also change the node and npm ports so that the different versions don't conflict with one another My approach was to use the user's nodejs/npm wherever possible. If their version is too old, show them how to deactivate it and ask them to try again. This would then install the latest version as a dependency of the port. > Making such a portgroup seemed difficult due to the need to track all of the > dependencies and their versions, a task for which MacPorts was not designed. > However we now have the cargo portgroup which does a similar task so maybe > those methods can be adapted for npm. I'll give it my best shot, but I have a feeling that this might be too difficult for the time being. If I'm not able to get it working, I'll still submit what I've got since it's an improvement for the npm ports that are already present. Maybe someone else might have an idea on how to do this, or we can work on this in the future. As part of getting this all submitted, I'll send a PR with Josh's suggestion for a separate "npm-1.0" PG tomorrow. Thanks for your help. -- Haren
OpenPGP_signature
Description: OpenPGP digital signature
