feat(access): add new `get`, `set` & `list`

[darcyclarke]

Summary

The CLI should support automation tokens (which are already available on the website). Currently, npm access has a binary understanding of 2fa support with the subcommands 2fa-required & 2fa-not-required, we should expand the set of subcommands to better consolidate functionality & not arbitrarily expand the subcommands required to manage this config.

Exit Criteria

• [ ] add new list subcommand with positional args of <packages|collaborators> & alias (npm access ls)
  • note: consider moving this functionality/information into npm view
  • ex. npm access list packages [<user>|<scope>|<scope:team>]
  • ex. npm access list collaborators [<package> [<user>]]
  • ex. npm access ls packages @darcyclarke
• [ ] add new get <key> & set <key=val> subcommands with the following keys/values:
  • status: public|private
  • mfa: false|publish|automation (alias: 2fa)
• [ ] Tests are written to reflect new capabilities
• [ ] Documentation is updated to reflect new capabilities

Examples

npm access get status lodash # "public"
npm access get status @secret/private-pkg-ex # "private"

npm access set status=private lodash # sets the public accessibility of the package to private

npm access set mfa=publish lodash # sets a 2fa requirement for publishing with publish tokens
npm access set mfa=automation lodash # sets a 2fa requirement for publishing with automation tokens
npm access set mfa=false # turns off 2fa requirements for publishing

References

• https://www.npmjs.com/settings/<tokens>/tokens
• https://github.blog/changelog/2020-10-02-npm-automation-tokens/

[darcyclarke]

@wraithgar can you look into this as a new API surface area? It should essentially replace the legacy subcommands (ref. https://github.com/npm/statusboard/issues/500) but shouldn't expand the functionality if we don't have the APIs to support that.

[wraithgar]

There is no registry api surface area to view a package's access other than status (i.e. public/private).

[wraithgar]

Changing mfa=false to mfa=none so that the code doesn't have 'false' strings it's parsing. Having a string with a value false is a little confusing. We can bike shed this before v9 lands.

[ljharb]

Why <key>=<val> exactly? That seems awkward, especially if i can't npm access set mfa=none status=public etc.