oof, this seems like a dangerous shortcut, especially since outside of npm itself, nobody should really be using bundledDeps at all. maybe instead of documenting it, we could pursue removing it?

I'm not sure how this can be dangerous, it seems to do exactly what you would expect it to do, isn't it?

There are plenty of use cases were you would want to bundle everything, including all use cases where you don't want to distribute your app via the programming language package manager. This is generally the case for everything that's not a library or a dev tool. In particular, when writing backend code in nodejs, it's common to have to move the app on a server for deployment, where most likely there is no internet access, and no package manager installed on the production machines. Some people are using docker for this kind packaging, and even for this use case, having a single dependency-free tgz package that you can ADD in your dockerfile can be super convenient on some CI setup.

I know that many people like using front end bundlers (esbuild, webpack) for this kind of thing that bundles everything in a single file, but bundledDepencies seem much simpler and works well.

I'll update the PR to rebase and remove the non doc commit.

@forty frontend bundlers aren't impacted by bundledDeps either way, because they have to build a single javascript file suitable for consumption in browsers. For Docker, you can just tar up the existing app with node_modules; bundledDeps only really matters if you're using npm publish.

@wraithgar while that is true, "documenting the current reality" is not always a good thing. Some functionality is best left undocumented.

@ljharb you are not wrong in the sense that today I can simply npm ci --prod then tar my js file with my node_module folder to achieve something similar to npm pack with "bundledDependencies": true (and it is what I do indeed)

However, and the main reason why I ended up reading the code in the first place, I would like to use the workspace feature of npm. And with the workspaces, bundling a tarball with only the dependencies required for a given package of the monorepo is much trickier. And I hoped that bundledDependencies would to that for me.

Now it turns out that bundledDependencies does not work well with workspaces at the moment :) (see #2207 and #3466). But when it does, I do feel the feature would be useful.

(And to add to this, I would absolutely agree if you would argue that adding a --bundle-deps parameter to npm pack would be nicer than a property in the package.json)

@ljharb you are not wrong in the sense that today I can simply npm ci --prod then tar my js file with my node_module folder to achieve something similar to npm pack with "bundledDependencies": true (and it is what I do indeed)

However, and the main reason why I ended up reading the code in the first place, I would like to use the workspace feature of npm. And with the workspaces, bundling a tarball with only the dependencies required for a given package of the monorepo is much trickier. And I hoped that bundledDependencies would to that for me.

Now it turns out that bundledDependencies does not work well with workspaces at the moment :) (see #2207 and #3466). But when it does, I do feel the feature would be useful.

Bump this... I'm having the same problem when trying to make docker images for services inside a monorepo. Packing workspaces with bundled dependencies would help a lot with that!

(And to add to this, I would absolutely agree if you would argue that adding a --bundle-deps parameter to npm pack would be nicer than a property in the package.json)

Also, this would be a nice addition.