Skip to content

namespace the install-script approval commands #9545

Description

@JamieMagee

Follow-up from RFC #868 (make install scripts opt-in), tracking the command-naming discussion at npm/rfcs#868 (comment).

Background

npm v11.16.0 shipped two top-level commands, npm approve-scripts and npm deny-scripts. Both are thin subclasses of lib/utils/allow-scripts-cmd.js, registered in lib/utils/cmd-list.js. The verb-noun shape came from pnpm (pnpm approve-builds), and it doesn't match how npm normally groups related operations: npm cache <cmd>, npm team <cmd>, npm token <cmd>, npm org <cmd>.

Proposal

Add one namespaced command and keep the verb-noun forms as aliases (they've shipped, so this stays backwards compatible):

  • npm install-scripts approve <pkg>... | --all
  • npm install-scripts deny <pkg>...
  • npm install-scripts ls (list unreviewed; see companion issue)
  • npm approve-scripts / npm deny-scripts alias to the above

Names raised in the thread:

  • npm install-scripts (favoured by @bakkot)
  • npm scripts (rejected: clashes with the scripts block and npm run)
  • npm trust (rejected: npm trust already exists)
  • npm hooks, npm lifecycle

@owlstronaut suggested aliasing the current commands and adding the namespace in Phase 2.

Notes

  • install-scripts says what it does, so it's the strongest candidate.
  • A namespace also gives the pending listing a home (install-scripts ls), which removes the --allow-scripts-pending ambiguity (companion issue).
  • The native-dependency-patching RFC (#804 #862) made the same move from verb-noun commands to subcommands; keeping these consistent is worth it.
  • No RFC needed. The command surface is additive and can be re-aliased later.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions