Cli: npm v7

Created on 19 Feb 2020  路  6Comments  路  Source: npm/cli

V7 Integration Work

Next (https://github.com/npm/cli/issues/971)

  • finish updating npm install command
  • update npm ci using arborist

    • nukes node_modules, and requires package-lock or npm-shrinkwrap file to work
    • I think that this is effectively: 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

  • update all instances of npm-lifecycle

    • update npm run-script with @npmcli/run-script


Beyond

  • update audit command
  • update funding command

    • can probably leverage scripts/funding.js

  • update npm ls command

    • needs to use arborist

  • update dedupe command

    • is const opts = { preferDedupe: true } the same thing?

    • (isaacs): not exactly. 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.)

  • update npm link command
  • update npm prune command

    • should be able to do const opts = { prune: true } to arb.reify. Note that this is the default anyway. Effectively, npm prune is an alias for npm install, then?

  • update npm uninstall command

    • arborist.reify({ rm: args })


Chores

  • remove figgy-pudding from CLI: (https://github.com/npm/cli/issues/970 / https://github.com/npm/statusboard/issues/78)

    • [x] libnpmaccess
      libnpmconfig(Not needed, no longer a dep of the CLI.)
    • [x] libnpmhook
    • [x] libnpmorg
    • [x] libnpmpublish
    • [x] libnpmsearch
    • [x] libnpmteam
    • [x] npm-profile
    • [x] CLI
  • remove deps:

    • [ ] bluebird
    • [ ] mississippi

Untriaged

  • teach Arborist how to do global/global-style installations. https://github.com/npm/arborist/pull/49
  • remove all the lockfile stuff
  • add 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:

    • mkdirp: (requires update of all uses. The API doesn't accept callbacks anymore; always promises returned) Note that most places where we're using gentle-fs.mkdirp, we can instead use mkdirp-infer-owner, since that does the same thing.
Enhancement Epic Release 7.x

All 6 comments

Note:

  • Remove bluebird
  • Remove 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:

  • read the package.json, if something exists somewhere, put it in the new place. (Then arborist reads it again? that.... sucks?)
  • teach arborist how to install something _without_ specifying where it goes in the package.json. (Eg, there's something by that name already, and it's dev, make it dev.) More API surface area here, kinda don't love that either, but might be more elegant to pass in 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

admosity picture admosity  路  4Comments

jaydenseric picture jaydenseric  路  3Comments

darcyclarke picture darcyclarke  路  3Comments

darcyclarke picture darcyclarke  路  4Comments

ahuglajbclajep picture ahuglajbclajep  路  3Comments