NPM-PRUNE(1)

πŸ’… npm-prune(1) β€” the "bestie, let's clean your node_modules" page

okay so this is npm-prune(1), the npm manual page that teaches you how to yeet your extraneous packages. it's short, it's iconic, and by the end you'll be pruning like a main character. 🧹✨


✨ NAME ✨

npm-prune β€” remove extraneous packages. that's it. that's the whole vibe. πŸ—‘οΈ

🌸 SYNOPSIS 🌸

npm prune [[<@scope>/]<pkg>...]

πŸ¦‹ DESCRIPTION πŸ¦‹

bestie. listen. this command removes "extraneous" packages. if you give it a package name, then only the packages matching one of the names you supplied get removed β€” so you can be surgical about it πŸ’…. no name? it goes for everything extraneous.

so what even is an extraneous package? it's a package that's chillin' in your node_modules folder but is not listed as any package's dependency list. like, who invited you?? πŸ™ˆ nobody, that's who. it's giving squatter energy.

now here's the tea β˜• β€” if the --omit=dev flag is specified, or the NODE_ENV environment variable is set to production, this command will remove the packages specified in your devDependencies. bye-bye dev stuff, you're not needed in prod, no cap.

if the --dry-run flag is used, then no changes will actually be made β€” it's just a little rehearsal, a dress rehearsal, a vibe check πŸ‘€.

if the --json flag is used, then the changes npm prune made (or would have made with --dry-run) are printed as a JSON object. data girlies stay winning πŸ“Š.

and here's the fun part: in normal operation, extraneous modules are pruned automatically, so you'll only need this command with the --production flag. but babes, in the real world 🌍, operation is not always "normal". when crashes or mistakes happen, this command can help clean up any resulting garbage. it's literally the cleanup crew of npm πŸ”₯🫢.


πŸŽ€ CONFIGURATION πŸŽ€

πŸ’œ omit

  • Default: 'dev' if the NODE_ENV environment variable is set to 'production'; otherwise, empty.
  • Type: "dev", "optional", or "peer" (can be set multiple times)

dependency types to omit from the installation tree on disk. like, don't even put them on disk, they're not coming to the party πŸšͺ.

big caveat though: these dependencies are still resolved and added to the package-lock.json file. they're just not physically installed on disk. so they're on the guest list but they're not in the building. iykyk.

if a package type appears in both the --include and --omit lists, then it will be included. include wins, periodt πŸ‘‘.

also: if the resulting omit list includes 'dev', then the NODE_ENV environment variable will be set to 'production' for all lifecycle scripts. so it ripples out, bestie 🌊.

🌈 include

  • Default: (empty)
  • Type: "prod", "dev", "optional", or "peer" (can be set multiple times)

this is the option that lets you define which types of dependencies to install πŸ›οΈ. it's the inverse of --omit=<type> β€” literally the mirror image πŸ’«.

dependency types specified in --include will not be omitted, regardless of the order in which omit/include are specified on the command-line. so don't try to out-order it, it doesn't care about your sequencing βœ‹.

⭐ dry-run

  • Default: false
  • Type: Boolean

indicates that you don't want npm to make any changes and that it should only report what it would have done πŸ—£οΈ. this can be passed into any of the commands that modify your local installation, eg, install, update, dedupe, uninstall, as well as pack and publish.

Note: this is NOT honored by other network related commands, eg dist-tags, owner, etc. so don't come for me when it ignores you 😭.

πŸ”₯ json

  • Default: false
  • Type: Boolean

whether or not to output JSON data, rather than the normal output πŸ“¦.

  • In npm pkg set it enables parsing set values with JSON.parse() before saving them to your package.json.

not supported by all npm commands. so like, check first, don't assume πŸ’€.

πŸ“ foreground-scripts

  • Default: false unless when using npm pack or npm publish where it defaults to true
  • Type: Boolean

run all build scripts (ie, preinstall, install, and postinstall) scripts for installed packages in the foreground process, sharing standard input, output, and error with the main npm process 🎀.

Note: this will generally make installs run slower, and be much noisier, but can be useful for debugging. loud and slow but honest, honestly 🫢.

🧚 ignore-scripts

  • Default: false
  • Type: Boolean

if true, npm does not run scripts specified in package.json files πŸš«πŸ“œ.

note that commands explicitly intended to run a particular script β€” such as npm start, npm stop, npm restart, npm test, and npm run β€” will still run their intended script if ignore-scripts is set, but they will not run any pre- or post-scripts. the main event still happens, the openers get cancelled πŸ™ˆ.

setting ignore-scripts also disables .npm-extension execution, as if ignore-extension were set. two-for-one, lowkey πŸŽ€.

πŸ’– workspace

  • Default: (empty)
  • Type: String (can be set multiple times)

enable running a command in the context of the configured workspaces of the current project while filtering by running only the workspaces defined by this configuration option πŸ”.

valid values for the workspace config are either:

  • workspace names
  • path to a workspace directory
  • path to a parent workspace directory (will result in selecting all workspaces within that folder)

when set for the npm init command, this may be set to the folder of a workspace which does not yet exist, to create the folder and set it up as a brand new workspace within the project. baby workspace, born fresh 🐣.

this value is not exported to the environment for child processes. keep it in the family, don't leak it ✨.

πŸ¦‹ workspaces

  • Default: null
  • Type: null or Boolean

set to true to run the command in the context of all configured workspaces 🌐.

explicitly setting this to false will cause commands like install to ignore workspaces altogether. when not set explicitly:

  • commands that operate on the node_modules tree (install, update, etc.) will link workspaces into the node_modules folder.
  • commands that do other things (test, exec, publish, etc.) will operate on the root project, unless one or more workspaces are specified in the workspace config.

this value is not exported to the environment for child processes. same deal as above πŸ’œ.

🌸 include-workspace-root

  • Default: false
  • Type: Boolean

include the workspace root when workspaces are enabled for a command 🏠.

when false, specifying individual workspaces via the workspace config, or all workspaces via the workspaces flag, will cause npm to operate only on the specified workspaces, and not on the root project. root stays home, sorry root 🌿.

this value is not exported to the environment for child processes. consistently un-leaky, we love that πŸ’….

  • Default: false
  • Type: Boolean

when set, file: protocol dependencies will be packed and installed as regular dependencies instead of creating a symlink πŸ”—βž‘οΈπŸ“¦. this option has no effect on workspaces. nope, zero, zilch, not for workspaces 🚫.


🫢 SEE ALSO 🫢

  • npm help uninstall
  • npm help folders
  • npm help ls

and that's the page, bestie!! 🌟 go forth and prune responsibly. this was npm-prune(1) from NPM@12.2.1, dated October 2026 β€” mwah, love u, don't forget to clear out your extraneous packages πŸŽ€πŸ’–βœ¨

πŸ“¦ where this page comes from