[RFC] Run `prepare` Scripts of Linked Bundled Dependencies

[mysterycommand]

cc/ @mikemimik @darcyclarke @isaacs

Motivation

Following discussion on #477 and previously on #463, workspaces that depend on sibling workspaces via the file: protocol (a.k.a. linked or symlinked dependencies) should run the sibling workspaces' prepare scripts as part of the depend-ing workspace's pack operation when those sibling dependencies are also specified as bundle/d dependencies (e.g. their "built" output should make it into the packed workspace's tarball).

Example

app-a and pkg-b are workspaces in a monorepo. app-a depends on pkg-b and lists it as a bundledDependency because app-a is expected to be distributed as a Node app somewhere (AWS Lambda, Docker, etc.) where it should be deployed along with its production dependencies. pkg-b is not published to a registry for reasons, and is written in a language or standard that must be compiled or transpiled to be runnable in Node (TypeScript, ES2049, etc.).

Assuming app-as package.json contains this:

{
  "name": "app-a",
  "version": "1.0.0",
  "dependencies": {
    "pkg-b": "file:../pkg-b"
  },
  "bundleDependencies": [
    "pkg-b"
  ]
}

… and pkg-b's package.json contains this:

{
  "name": "pkg-b",
  "version": "1.0.0",
  "scripts": {
    "prepare": "tsc"
  }
}

… with the appropriate tsconfig.json, .npmignore, and index.ts in pkg-b, running cd app-a ; npm i --package-lock=false ; npm pack should produce a tarball with contents like:

app-a
├── node_modules
│   └── pkg-b
│        ├── index.js
│        └── package.json
└── package.json

How

Current Behaviour

This is currently possible (I think) but it's "hacky" and involves a lot of plumbing and orchestration to make sure various package scripts are executed in the right order.

Desired Behaviour

It just works as described in the example.

References

• Related to Multi-app Monorepo Followup #477
• Related to [RRFC] Multi-app Monorepo Support #463
• Related to a forthcoming PR about workspace/dependency layout from @ljharb
• Discussed at Open RFC Meeting - Wednesday, October 20, 2021, 2:00 PM EST #478

---

Edit: updated to reflect this is an RFC, not an RRFC … I think that's right?

[mikemimik]

@mysterycommand did you mean for this to be an RRFC or an RFC?

Sub note: I'm wondering if the process we move forward with should take into account this RFC: #403. I don't necessarily want to mung those two ideas together, but they are opposing sides to the same coin. (cc. @isaacs wdyt?)

[mysterycommand]

@mysterycommand did you mean for this to be an RRFC or an RFC?

Ahh yeah, sorry I was moving too fast. There's no formal format for RFCs though, can I just change the title? Do I need to add a label or something? … anyway, updated the title, removed references to RRFC.

[mikemimik]

@mysterycommand for RFC's they are a PR with a created document the link below describes how :)

https://github.com/npm/rfcs#how-do-i-create-an-rfc

[mysterycommand]

@mysterycommand for RFC's they are a PR with a created document the link below describes how :)

https://github.com/npm/rfcs#how-do-i-create-an-rfc

Ahhh … okay, dang. I'll do that in a bit then.

[mikemimik]

@mysterycommand for RFC's they are a PR with a created document the link below describes how :)
https://github.com/npm/rfcs#how-do-i-create-an-rfc

Ahhh … okay, dang. I'll do that in a bit then.

Once you've got something going, I can either comment on it to contribute, or you can add me as a contributor on your forked repo with push privs and I can also commit to the document. That second bit might be tricky, so maybe I can just comment my contributions or we can collab on a markdown doc with something like https://hackmd.io/ and then you can submit the PR.

[mysterycommand]

@mikemimik added you as a contributor to my fork mysterycommand/rfcs. I don't really have a preference for how we collaborate on this (I don't mind if you just want to commit right into my fork). It's mostly a copy/paste of the above for now. Closing this in lieu of the fork.