-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Description
Currently it doesn't. The complete node_modules/<bundled_pkg> directory as it appears after npm install is packed without filtering. Files not required at runtime are packed too, leading to unnecessary big tarballs.
There are at least two scenarios where matching ignore rules of bundledDependencies would IMO make sense:
- If you depend on native addons that get compiled locally: Intermediate build artifacts (*.o, stripped debug symbols, ...) are created during compilation and are currently packed. Those are not needed in production, and would usually be filtered if the .npmignore of the native addon would be considered.
- If you bundle git/file dependencies: They're basically
npm installed in their "unpublished state".npm publishhasn't already been run for them and .npmignore hasn't been applied yet. Any kind of production-unrelated files like tests, non-js, non-node stuff may be there and is currently packed. That stuff is not needed in production, and would usually be filtered if the .npmignore of the git/file dependency would be considered.
Background: I'm using npm pack + bundledDependencies to generate self-contained tarballs for deployment where size matters and build/deploy/runtime dependency on "the internet" is mostly a no no. There's even more I'd like to filter out, like *.c/*.h and dead JS code, but obviously .npmignore will never help there. pkg and webpack seem to approach the latter case, but I read about pitfalls when it comes to native addons, so I think they're not the right tool either?