[BUG] Workspaces - bundledDependencies missing in tarball after npm pack

[noelvillagonzalo]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

In a project with workspaces, run "npm install" and then "npm pack -w a" from the root. Packages specified under bundledDependencies of package/a are NOT included inside the node_modules of the resulting tarball (a-1.0.0.tgz)

Expected Behavior

Packages specified under bundledDependencies of package/a are included inside the node_modules of the resulting tarball (a-1.0.0.tgz)

Steps To Reproduce

1. Clone this sample repository
2. Ensure you are running npm >= 7
3. Run npm install in the root of the repository
4. Run npm pack -w a in the root of the repository
5. Inspect the resulting tarball (a-1.0.0.tgz)
   -> Missing bundledDependencies package in node_modules, although package/a declares bundledDependencies

Environment

• OS: macOS 10.15.17
• Node: 15.8.0
• npm: 7.18.1

[everett1992]

If you install dependencies in the package, instead of the workspace root, bundled dependencies will be included

$ cd packages/a
$ npm install
$ npm pack
$ tar --list -f a-1.0.0.tgz

package/node_modules/...

bundled dependencies will be included as long as node_modules are located in the package directory.

# after running the previous script and installing node_modules inside packages/a
npm-issue-missing-bundled-dependency $ npm pack -w a
npm-issue-missing-bundled-dependency $ tar --list -f a-1.0.0.tgz
package/node_modules/...

I don't think this is a good behavior, a workspace package's dependencies should be included in the bundle even when they are hoisted to the workspace root. If a workspace package depends on another workspace package that isn't published you can't run npm install outside the workspace root.

[niknetniko]

Anyone have a workaround for when you depend on another workspace package?

[jmrtinb]

Currently running into exactly this problem, would really like to have a way to pack a package in a workspace, which depends on other packages in the workspace and have all the bundled dependencies included in the archive properly. I haven't found a satisfactory way to work around the issue yet.

[bmeeder22]

+1

[chordmemory]

This is a real dealbreaker imo for the bundleDependencies feature as most use cases involve a workspace approach

[jamie-pate]

Cheap hack using find inside the inner workspace for bundling other scoped packages from the workspace

{
  "scripts": {
    "build": "npm run tsc && ../esbuild.config.mjs && npm run bundle && ../npm_pack.sh && rm -r ./node_modules/@myscope",
    "bundle": "find ../node_modules/@myscope/* -exec bash -c 'echo $0; mkdir -p ./node_modules/@myscope/$(basename $0); cp -R \"$0/\"* ./node_modules/@myscope/$(basename $0) 2>/dev/null; echo done' '{}' \\;"
  },
  "dependencies": {
    "@myscope/mypackage": "^0.0."
  },
  "bundledDependencies": [
     "@myscope/mypackage"
   ]
}

[ViktorLajos]

+1

[antoniofruci]

+1

[hps8891]

+1

Need support for npm bundle dependencies

$ node -v
v16.18.1

$ npm -v
8.19.2

[TimothyJones]

This is still happening with npm 9.6.4, and is the cause behind aws/jsii#4132

It would be really cool if this could be sorted <3

[terozio]

This severely limits usability of workspaces in cases where bundles need to be included. Any hope of getting attention to fix it?

[pedroresende]

the only workaround so far it's to use an old version of npm to do the packing....

[mcdurdin]

keymanapp/keyman#9536 shows the pattern we plan to use to workaround this issue, for now.

[jcable]

I've incorporated a fix for this into our semantic-release plugin. It's a private repo so linking a gist to the relevant functions

https://gist.github.com/jcable/8ee152e3f5a05a47b286029e9e654984

review and comments welcome.

[TimothyJones]

@jcable Do you think you'd be able to turn your gist into a PR? I'd like to review it, but I'm not sure where / what is changing -and I'd love to have a fix for this issue.