Monorepo support

[wbcs]

Updated issue

Bun supports "workspaces" in package.json, "workspace:* (protocol) in dependencies, and many more features related to workspaces. See the docs page on workspaces.

You can also use bun run --filter="*/*lib" to run multiple package.json scripts from different packages within a workspace simultaneously and view tail the logs - see the docs.

We're keeping this issue open for now, but it's not entirely clear what's left to close it.

Original issue below

---

What is the problem this feature will solve?

bun not support monorepo(root package.json workspaces field, workspace:* schema, etc.)

What is the feature you are proposing to solve the problem?

The download speed of monorepo will be faster

What alternatives have you considered?

No response

[Jarred-Sumner]

yes, but probably not for a little while

[FinnRG]

Related: The workspace: field progress is tracked in #83.

[davidmeirlevy]

can the implementation of workspaces include:

1. the ability to have separated node_modulues on each workspace.
2. the equivalent of lerna exec to execute any command inside the workspaces, even if it's not inside the package.json.
   for example, I want to run bun dev on each workspace, but the dev itself probably won't be a script inside the package.json of each workspace. the same for tests...

[factoidforrest]

I just want to say that I haven't missed lerna exec at all after ditching lerna for pure yarn workspaces. Things like that are certainly nice-to-haves but I don't think going any further than the support provided by yarn or NPM is necessary as a first-pass.

[davidmeirlevy]

@factoidforrest yarn has yarn exec that can work on workspaces, so it's equivalent.

[unional]

Maybe consider monorepo support similar to turbo and rush. They are both very efficient.

[wbcs]

nsider monorepo support similar to turbo and rush. They are both very efficie

I prefer pnpm

[unional]

I prefer pnpm

npm/yarn/pnpm are orthogonal to lerna/turbo/rush. One are package managers, the others are monorepo tools.

[davidmeirlevy]

I prefer pnpm

npm/yarn/pnpm are orthogonal to lerna/turbo/rush. One are package managers, the others are monorepo tools.

He probably meant to pnpm workspaces.
I also prefer this way, because of the full scope isolation for each package.

[ozyman42]

I prefer pnpm

npm/yarn/pnpm are orthogonal to lerna/turbo/rush. One are package managers, the others are monorepo tools.

He probably meant to pnpm workspaces. I also prefer this way, because of the full scope isolation for each package.

Yarn 2+ Plug n Play also has full scope isolation for each package. A main reason the pnpm resolution strategy might be preferable to Plug n Play is because notable projects such as React Native are currently incompatible with Plug n Play. On the flip side, Plug n Play might be considered preferable because it may solve the doppleganger problem differently than pnpm (someone ought to investigate this comparison in detail). Personally I find the "non-single singletons" doppleganger consequence the most important one because it's the root cause behind monorepo bugs involving popular libraries such as graphql-js.

Overall though I think Bun should make an authoritative choice for workspaces/monorepo support rather than letting this be highly configurable. Too much configurability leads to too much project complexity both in implementation and from a client's point of view w/ too many options to choose from & too much boilerplate. Bun needs to have a clear story for workspace/monorepos before it can be seriously considered for adoption by medium to large projects.

[unional]

Agree. IMO pnpm doppleganger solution is also the way to go.

The point I want to make by bring yo turbo and rush is the ability to efficiently running multiple scripts with dependencies.

For example:
https://turborepo.org/docs/core-concepts/pipelines
https://rushjs.io/pages/advanced/incremental_builds/
https://rushjs.io/pages/developer/selecting_subsets

[wbcs]

Agree. IMO pnpm doppleganger solution is also the way to go.

The point I want to make by bring yo turbo and rush is the ability to efficiently running multiple scripts with dependencies.

For example: https://turborepo.org/docs/core-concepts/pipelines https://rushjs.io/pages/advanced/incremental_builds/ https://rushjs.io/pages/developer/selecting_subsets

turborepo is greate.
but how rush run custom npm scripts in subsets? It run reserved keyword instruction only.

[unional]

but how rush run custom npm scripts in subsets? It run reserved keyword instruction only.

It does not. rush has it's own way to add commands to the system.
(to run custom npm scripts in one package, use rushx run ...)
I personally like turbo better too. The rush system sounds too heavy and rigid to me (I tried both).
Also mentioning rush here for completeness and also may able to draw an idea or two from it's selective script execution (those from/to/since things).