Per #84, it is not safe to publish npm packages with ed dependencies. This notice should be prominent in -package documentation.

Note: I don't expect this PR to be merged as it, but rather start a conversation about how to more clearly communicate the use cases for -package.

[laurent22]

The "why?" part is missing. Either it's obvious why it shouldn't be done, and there's no need to add this to the readme, or it's not, and that should be explained.

My use case is publishing a CLI application and use -package to fix some of the dependencies. It has worked fine for years but lately there's a bug and when I search for some info there's the same "it's not safe" being repeated many times, but it's not explained why or what should be the alternative.

[papb]

Good question. I don't know the why either. I just saw this comment.

[davidmurdoch]

I believe it is because es are applied to a specific file in your node_modules folder, but when a package is installed by end users the node_modules dependency tree may shift things around, and this shifting could be due to factors that can't be controlled by -package.

Also, if the dependency you are ing is also imported by the user of your package, package shouldn't that version of the package... which is not really possible, at least not without some really weird shenanigans.

To work around this issue I used package.json's bundleDependencies to include the actual dependency I ed in my published package.

[papb]

@davidmurdoch Nice! By the way, I've used bundleDependencies in the past for something else in the past, it works well with npm but I've met an issue with yarn...

[davidmurdoch]

Good to know!

[laurent22]

Thanks for clarifying @davidmurdoch, perhaps your comment or a shortened version of it could be included in the readme?

Just wanted to bump this as I didn't catch that this was not supported until I found this thread.

As mentioned by @papb (#270 (comment)), one way to solve the problem when ing the dependencies of a package that you intend to publish is to use bundledDependencies to make sure it's used and also use npm's prepare  script hook rather than postinstall. If you are ing an indirect dependency, you need to bundle the whole dependency chain up to the ed package otherwise the intermediate dependencies may be installed "higher" in the host project's node_modules and end up using an uned version of the dependency.

I recommend against making -package a production dependency and running it via postinstall in a package you publish, because it introduces the risk that the ing fails due to a different deduped version of the dependency that prevents your from applying cleanly. For instance, if your applies to [email protected] but [email protected] or higher gets installed in the project, your might not apply cleanly and causes installation errors. (Friction for users of your package.) Not to mention that even if it applies cleanly, the may be useful to your package, but harmful to other consumers of the shared dependency.

How is this still not included in the README?

It's a very severe limitation! I certainly wish I had known before using this... for it to not work at all in the end. Pardon me for being this straightforward, but I wasted precious time trying to make this work and searching for answers.

Please, for the sake of others who could be in my situation in the future: be explicit about this limitation in your README.

Thank you.

It'd be good to get this merged to document that this isn't intended.

As noted in #198 (comment) I managed to make this work as a workaround (when distributing an executable) but it may help folks save some time trying to work out how to do it, if they realise it's not recommended