Project references: Option to bundle dependencies with multi-file output

[mattmccutchen]

Search Terms

"project references" bundle copy dependencies

Suggestion

When using project references, add an option to bundle a project's dependencies when using outDir. This would be the analogue of prepend, which only works with outFile. This would be useful when targeting a module format that doesn't work with outFile, such as commonjs.

Use Cases

Two Stack Overflow questions today:
https://stackoverflow.com/questions/51938528
https://stackoverflow.com/questions/51939395

For the specific case of CommonJS output, I had the idea to generate single-file AMD output and then use amdefine to wrap the result as a CommonJS module. This sort of works but is extremely ugly.

Edit: I realized that both the prepend option and the suggested option are of limited use for composite projects with external dependencies, because a separate tool is needed to aggregate the external dependencies, and that tool may be able to aggregate the components too. Concretely, if the components have external dependencies in node_modules, then the inter-component dependencies can be added to package.json using relative paths and npm install will make symlinks under node_modules, so if the packaging tool is capable of following those symlinks, it will pack everything up. (A similar technique to make symlinks is possible using yarn workspaces instead of dependencies with relative paths, and has in fact been used to solve https://stackoverflow.com/questions/51939395 .) However, symlink support is still uneven on Windows, as pointed out here.

I'm still interested in the rationale for offering prepend and not the analogous thing for multi-file output. Was it just that prepend was designed to suit the needs of the TypeScript compiler?

Examples

Straw-man proposal:

{
  "references": [
      { "path": "foo", "copyOutDirTo": "some/path" },
  ]
}

Copies the outDir of the referenced project to some/path. By specifying copyOutDirTo and the project's own outDir in the correct relationship, one can produce a single output tree in which modules will be able to find each other.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

Possibly related

#17611

[RyanCavanaugh]

This could use some more specification. What does "bundle" mean in this context? Copy over? Roll into a single file? Something else? Should .d.ts files come along for the ride?

I'm still interested in the rationale for offering prepend and not the analogous thing for multi-file output.

Ship the minimum viable product, add more cruft later as feedback appears 😉

Was it just that prepend was designed to suit the needs of the TypeScript compiler?

prepend is general-purpose for any outFile-based compilation

[ajhool]

Creating individual ts bundles for microservices in a monorepo has become a little bit of a nightmare due to recent improvements in dependency management, ironically. It had been as simple as copying node_modules into dist, zipping, and deploying to aws lambda.

Yarn workspaces, project references, and lerna all bring useful tooling but move dependencies into hard-to-reach places via hoisting or other magic. I expect a lot of people to be confused about how to build -> bundle w/ dependencies. Project references and workspaces are alluring but come with some possibly surprising hazards

[peterjuras]

Any updates on whether outDir based projects can be prepended?

[moroine]

Any update on this?

[bdaz]

+1 Would love to see this.

[DerGernTod]

i would also appreciate this getting a bit more of attention, especially in monorepo scenarios. here's my setup:

• packageShared
• packageA depends on packageShared
• packageB depends on packageBTypes
• packageBTypes depends on packageShared

now i want to publish packageBTypes to an internal npm repo, but not packageShared. it has only types but also re-exports some types of packageShared. however, i don't want to publish packageShared, which in the end causes issues because of the dependency. so when i install packageBTypes in some third party project, i get an error because packageShared cannot be resolved (of course, i didn't publish it). it would be great if i could move packageShared to devDependencies and use prepend: true to prepend its output dir to packageBTypes, so no third party has issues installing it.

imho it would be best if prepend: true would do the same thing in both scenarios. it can obviously detect if the project reference has an outFile or not, so it should be possible to also work with outDir, no?

[RyanCavanaugh]

prepend itself is being deprecated (#51909) so I think it's safe to say nothing else is happening in this space.