Linked bundledDependency doesn't respect npmIgnore


(James Bromwell) #1

What I Wanted to Do

I included a local dependency using npm link then created a package from my project using npm pack. I wanted the library I created to be included in the package so I put it in bundledDependencies. I expected npm pack to put the library package in the archive file, under node_modules.

What Happened Instead

The entire library directory was inserted into the tarball, including .git subdirectory and other files that would be excluded if I ran npm pack in the library directory.

Reproduction Steps

This is a simple test case.

  • In mylib, run npm pack to generate a tarball with just index.js and package.json. Note that bad.file is ignored as configured in the .npmignore.
  • Run npm link to register this package.
  • Now, back up to consumer and run npm link mylib then npm pack.
  • Check the tarball, and note that node_modules/mylib includes .npmignore and bad.file.

Platform Info

$ npm --versions
{ npm: '6.1.0',
  ares: '1.13.0',
  cldr: '33.0',
  http_parser: '2.8.0',
  icu: '61.1',
  modules: '59',
  napi: '3',
  nghttp2: '1.29.0',
  node: '9.11.1',
  openssl: '1.0.2o',
  tz: '2018c',
  unicode: '10.0',
  uv: '1.19.2',
  v8: '6.2.414.46-node.23',
  zlib: '1.2.11' }
$ node -p process.platform

(James Bromwell) #2

I posted this in the bug topic, because this doesn’t seem right, but maybe this is how it’s supposed to work? If there’s a better way to do this – develop a dependency locally, then use it in another project without going to the hassle of setting up my own npm repo to publish it in properly – I’m open to doing that instead.

(James Bromwell) #3

There’s really two issues here. Both the npmignore in the library and the npmignore in the consumer aren’t applied when bundledDependencies are included by npm pack. This means that not only is bad.file included in spite of having it in mylib/.npmignore, it also means that I can’t filter any of the content included by bundledDependencies using consumer/.npmignore – I have absolutely no way of controlling the final result.

(James Bromwell) #4

I hate to keep replying to my own post but I keep finding rough edges. Please let me know if this should go in a separate report, but: trying to npm install or npm uninstall in a package that includes a link'd entry in bundledDependencies causes an error. You can remove the entry, run npm install (or npm uninstall), then replace the entry before running npm pack and it shows the above behavior, but this limitation really diminishes the value of npm link – dependencies provided by link are kind of second-class.

(Kat Marchán) #5

npm link is basically broken, and we’re in the middle of redesigning a complete overhaul right now. Pointing out these rough edges is useful but it won’t be actually fixed until npm@7, when we replace the current link/unlink commands. See New npm link command. (note: this RFC is about to get another overhaul soon, itself). We’re expecting to have npm@7 and certain things built on top of it by end of year.

(James Bromwell) #6

Thanks for following up. I’ve been reading the RFC and it looks like pack / publish will not support link at all after the overhaul. Do you know if there’s a suggested workflow that supports my use case? I want to develop the dependency and the consuming package in tandem, and be able to pack the consumer to conveniently test it on an offline (non-networked) system. Maybe there’s a better way?