Have you checked for existing feature requests?
Summary
In theory, it is good for us to move away from a model where ppm maintains its own fork of npm. As far as I can tell, all the tasks that ppm delegates to npm (via spawning a child process) are things that can more properly be done via libraries.
@npmcli/arborist is the official way to manage a node_modules folder and reconcile it with its associated package.json and package-lock.json. This might allow us to vastly simplify much of the code in src/install.js and src/ci.js. @mauricioszabo has been mentioning this for ages and it's certainly worth taking a look at.
What benefits does this feature provide?
Better alignment around npm’s behavior without having to maintain an npm fork. More maintainable ppm code. Less ppm code.
In fact, this might obviate #158; arborist depends on pacote, so it might remove the need to directly look up tarball URLs and whatnot.
Any alternatives?
No, not really. The options are (a) the status quo and (b) this issue, since they represent the unofficial and official ways of replicating npm’s behavior, respectively. Even if there were a third option, it would only be another unofficial method, and I doubt that's worth considering.
Other examples:
No response
Have you checked for existing feature requests?
Summary
In theory, it is good for us to move away from a model where
ppmmaintains its own fork ofnpm. As far as I can tell, all the tasks thatppmdelegates tonpm(via spawning a child process) are things that can more properly be done via libraries.@npmcli/arboristis the official way to manage anode_modulesfolder and reconcile it with its associatedpackage.jsonandpackage-lock.json. This might allow us to vastly simplify much of the code insrc/install.jsandsrc/ci.js. @mauricioszabo has been mentioning this for ages and it's certainly worth taking a look at.What benefits does this feature provide?
Better alignment around
npm’s behavior without having to maintain annpmfork. More maintainableppmcode. Lessppmcode.In fact, this might obviate #158;
arboristdepends onpacote, so it might remove the need to directly look up tarball URLs and whatnot.Any alternatives?
No, not really. The options are (a) the status quo and (b) this issue, since they represent the unofficial and official ways of replicating
npm’s behavior, respectively. Even if there were a third option, it would only be another unofficial method, and I doubt that's worth considering.Other examples:
No response