From 5d23989f941966646d2adbde31e9b0972b9690ee Mon Sep 17 00:00:00 2001 From: RecuencoJones Date: Sat, 23 May 2020 09:53:58 +0200 Subject: [PATCH] RFC: Add file+pack dependency protocol --- accepted/0027-file-pack.md | 60 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 accepted/0027-file-pack.md diff --git a/accepted/0027-file-pack.md b/accepted/0027-file-pack.md new file mode 100644 index 000000000..db31768ec --- /dev/null +++ b/accepted/0027-file-pack.md @@ -0,0 +1,60 @@ +# new install protocol file+pack + +## Summary + +Imported from https://github.com/npm/cli/issues/1333 + +Add a way to install local folder dependencies by first running `pack` script to trigger any build process required to generate distributable files before linking generated tarball to requesting module. + +## Motivation + +{{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} +When using local package dependencies, they usually require a build process which should be triggered before linking. I've seen a similar issue to this one: https://github.com/npm/cli/issues/459#issue-520571016 + +Also a lot of times when using local package dependencies dependency hoisting and linking does not match the same as installing from a tarball, which has been reported in some issues before: + +https://github.com/npm/cli/issues/529#issuecomment-577635266 + +https://github.com/npm/cli/issues/702 + +From [@isaacs](https://github.com/isaacs) comments: + +> It seems like at least part of the need here stems from the fact that you want the `prepare` script to be run in the linked dep. Could we get part of the way with a flag to just tell npm to do that? Ie, `npm install --rebuild-links` or something? That flag would also be respected by default by the rebuild command, so you could do `npm rebuild --rebuild-links` when you know something's changed, and even set up a watcher to do that while in development. (This would be considerably faster than creating and unpacking a tarball.) + +## Detailed Explanation + +When resolving `file+pack` the following will happen: + +``` +package-b has prepack script? + npm install on package-b directory (dependencies + devDependencies) +npm pack +install generated package-b-1.0.0.tgz on package-a +``` + +## Rationale and Alternatives + +As per [@isaacs](https://github.com/isaacs) suggestions: + +> We might also explore something like pack:file:/path/to/folder, where pack: can be a prefix applied to any arbitrary spec? Then you could do something like pack:express@latest. It'd be extraneous in the case of git deps, where we already have to repack for consistency, but I'm wondering if there might be cases where it's worthwhile to re-generate a tarball that you get from a url or registry? Like if it is a url like https://my-company/module/src.tgz tarball of the raw src code that has to be built? + +## Implementation + +Sample raw implementation wrapping npm: https://github.com/RecuencoJones/npm-filepack + +Sample repository: https://github.com/RecuencoJones/filepack-example + + +## Prior Art + +We could consider every other monorepo management tool a prior art to this: + +- [Lerna](https://github.com/lerna/lerna) +- [Yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/) +- [Rush](https://github.com/microsoft/rushstack/tree/master/apps/rush) + +## Unresolved Questions and Bikeshedding + +As per [@isaacs](https://github.com/isaacs) comments: + +- Spelling of the protocol needs to be bikeshedded. I don't know off the top of my head any reason to prefer `file+pack:` vs `pack:` vs `pack+file:` etc., but I know we do test the resolved string against `/^file:/` in a few places to see whether it's a local dep, so all those code paths will have to be examined