npm install
commandupdate npm ci
using arborist
arb.loadVirtual().then(() => rimraf('node_modules')).then(() => arb.reify())
. Loading virtual explicitly will fail if there's no shrinkwrap. Then delete node_modules and do a reify with no additional options.create libnpmversion
npm-lifecycle
npm run-script
with @npmcli/run-script
scripts/funding.js
npm ls
commandarborist
const opts = { preferDedupe: true }
the same thing?preferDedupe
only takes effect when creating the ideal tree. Of course, if you're ok with abandoning the versions found in the package-lock, and taking updates to deps, then reify({ update: true, preferDedupe: true })
would do that. (Then effectively npm dedupe
becomes an alias for npm update --prefer-dedupe
. Not sure if this is desirable, but might be.)npm link
commandnpm prune
commandconst opts = { prune: true }
to arb.reify
. Note that this is the default anyway. Effectively, npm prune
is an alias for npm install
, then?npm uninstall
commandarborist.reify({ rm: args })
remove figgy-pudding
from CLI: (https://github.com/npm/cli/issues/970 / https://github.com/npm/statusboard/issues/78)
libnpmaccess
libnpmconfig
libnpmhook
libnpmorg
libnpmpublish
libnpmsearch
libnpmteam
npm-profile
remove deps:
bluebird
mississippi
scriptShell
and binLinks
configs to flatOptions (these were overlooked)avoid double-parsing npm-package-arg specifiers by making Arborist's Edge.spec an npa spec rather than a string.
run tests with --nyc-arg=--all
and delete any files in lib
that never get loaded. (Use this to generate the worklist, but verify that there's no require()
statements that would pull them in, of course.)
update deps:
gentle-fs.mkdirp
, we can instead use mkdirp-infer-owner
, since that does the same thing.Note:
bluebird
mississippi
One bug I noticed today in how we did install
for v7, which I'm thinking might be worth solving in Arborist, or maybe should just be set up in the CLI itself, not sure.
Basically, if you do this:
npm i [email protected] # saves in dependencies
npm i tap@12 -D # saves in devDependencies
# update them both...
npm i tap@latest abbrev@latest # updates tap in devDeps, abbrev in deps
Options:
add: { unspecified: [...] }
or something?Now, if you have something as a devDep _already_ and want to _move_ it into a production dep, you can do --save-prod
. So it's not enough to just always pass it in the add: { dependencies: [...] }
set, because sometimes we want it saved in its default location, and other times we want it explicitly saved in prod deps, even if it's already somewhere else.
I think I'm missing some context. When I read that example
npm i [email protected] # saves in dependencies
npm i tap@12 -D # saves in devDependencies
# update them both...
npm i tap@latest abbrev@latest # updates tap in devDeps, abbrev in deps
This seems like correct behaviour to me. Did you mean to say that if you run npm i tap@latest abbrev@latest
it will move the tap@latest
into the dependencies
section of the package.json
?
(should npx be included in any of the lists above?)
@ljharb npx
is a separate cli tool, and we definitely have plans to give it some love. The work on the cli with introducing the new versions of pacote
, cacache
, and arborist
will definitely inform how we get npx
up to snuff.
@mikemimik Yeah, in the current v7 branch, that's what it'll do. We didn't do the thing where we preserve the current save location, and arborist doesn't do that right now either. Arborist issue for this
@ljharb npx needs a pretty thorough refresh, and really has never gotten properly updated since back in the npm v5 line when it was created. The good-ish news is that it's not a blocker for a v7 beta, but we ought to tackle it before an official 7.0.0 release.