bun
bun copied to clipboard
oven-sh
Monorepo support
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
can the implementation of workspaces include:
- the ability to have separated node_modulues on each workspace.
- the equivalent of
lerna execto execute any command inside the workspaces, even if it's not inside thepackage.json. for example, I want to runbun devon each workspace, but thedevitself probably won't be a script inside the package.json of each workspace. the same for tests...
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.
@factoidforrest yarn has yarn exec that can work on workspaces, so it's equivalent.
Maybe consider monorepo support similar to turbo and rush. They are both very efficient.
nsider monorepo support similar to
turboandrush. They are both very efficie
I prefer pnpm
I prefer pnpm
npm/yarn/pnpm are orthogonal to lerna/turbo/rush. One are package managers, the others are monorepo tools.
I prefer pnpm
npm/yarn/pnpmare orthogonal tolerna/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.
I prefer pnpm
npm/yarn/pnpmare orthogonal tolerna/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.
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
Agree. IMO
pnpmdoppleganger solution is also the way to go.The point I want to make by bring yo
turboandrushis 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.
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).
Hi,
IMHO the only responsibility from Bun regarding workspaces is dependency resolution, the rest should be handled by a monorepo tool like Turbo or NX.
Is npm run SCRIPT_NAME --workspaces part of this issue, or does it need a separate one?
Related to previous comments: https://github.com/oven-sh/bun/issues/533#issuecomment-1179789422, https://github.com/oven-sh/bun/issues/533#issuecomment-1189655741
Per https://github.com/oven-sh/bun/issues/83 it looks like some support for workspace: protocol was added but it doesn't appear to work with pnpm workspaces. Did I miss something or are there still additional changes needed to allow bun to work with a pnpm monorepo?
Speed and disk space are the reasons pnpm is best for monorepos. Whenever multiple workspaces within a monorepo depend on the same npm package, npm and yarn download and install a separate copy of the npm package for each workspace, whereas pnpm symbolically links them all to the same download of the package. Yarn's PnP does muddy the waters a bit, but its problems keep me from using it. See the benchmarks.
Whenever multiple workspaces within a monorepo depend on the same npm package, npm and yarn download and install a separate copy of the npm package for each workspace
For yarn, it's configurable: https://yarnpkg.com/configuration/yarnrc#nmMode
I am not sure now, it isn't supported and described here? https://bun.sh/docs/install/workspaces Do I miss something or can this issue be closed as completed?
EDIT: I see it miss support for script execution inside monorepo, ex. pnpm run --filter mypackage start. Probably, should be tracked as a separate issue.
@Bessonov I'm not sure it should be considered completed so soon, there's several workspace related bugs and missing features (like filtering that you mentioned)
I went through the open issues, it looks like there's a bunch of duplicate, but we could use this issue as a tracking one.
- https://github.com/oven-sh/bun/issues/4830
- https://github.com/oven-sh/bun/issues/2517
- https://github.com/oven-sh/bun/issues/4628
- https://github.com/oven-sh/bun/issues/4274
- https://github.com/oven-sh/bun/issues/2232
- https://github.com/oven-sh/bun/issues/4174
- https://github.com/oven-sh/bun/issues/4650
- https://github.com/oven-sh/bun/issues/4676
- https://github.com/oven-sh/bun/issues/3582
- https://github.com/oven-sh/bun/issues/4366
- https://github.com/oven-sh/bun/issues/4621
- https://github.com/oven-sh/bun/issues/3502
- https://github.com/oven-sh/bun/issues/3806
- https://github.com/oven-sh/bun/issues/3686
- https://github.com/oven-sh/bun/issues/3677
- https://github.com/oven-sh/bun/issues/2773
- https://github.com/oven-sh/bun/issues/2938
- https://github.com/oven-sh/bun/issues/4447
@Hebilicious Thank you very much for the excellent overview! I am still of the opinion that documented basic use cases should work. So, the binary answer to this issue is "yes, a monorepo is supported". I am not opposed to leaving this issue open, but, in my opinion, it distracts from addressing actual problems. Alternatively, @wbcs could add your list to the top of this issue, making it a meta-issue for outstanding work.
I feel it's relevant to share this tweet that I saw from Jarred a couple of months ago. He mentioned wanting to have another go at implementing workspaces as he didn't think the support was that good, although I'm not sure if they ever got around to redoing it.
https://twitter.com/jarredsumner/status/1682860099528978432
Additionally plugging this issue: https://github.com/oven-sh/bun/issues/4844
@Hebilicious Thank you very much for the excellent overview! I am still of the opinion that documented basic use cases should work. So, the binary answer to this issue is "yes, a monorepo is supported". I am not opposed to leaving this issue open, but, in my opinion, it distracts from addressing actual problems. Alternatively, @wbcs could add your list to the top of this issue, making it a meta-issue for outstanding work.
It's hard to argue that bun has monorepo support in terms of a drop in replacement for pnpm. Replacing pnpm works for the most part, but as soon as you come to monorepos (which is very common in OSS and other projects these days), you have to redesign your whole CI/CD pipelines or have challenges that can be very hard to solve.
You can't just run bun run --filter "@scope/package1" build instead of pnpm run --filter "@scope/package1" build etc.. There is still a long way to go and I am willing to go it with bun, but it should be communicated transparently that there is no real monorepo support as people expect when coming from pnpm or yarn.
@itpropro I think (1) "doesn't fail when used in a monorepo", (2) "supports monorepos", and (3) "includes tools that make working with monorepos easy" are all valid but very different definitions of "monorepo support". Bun currently meets the criteria for (1), sort of meets the criteria for (2), but definitely does not meet the criteria for (3).
As evidenced by @Hebilicious's list (https://github.com/oven-sh/bun/issues/533#issuecomment-1712865027) and other comments here, there's a lot of work to do before that last criteria is met. Documentation should probably reflect that.
@itpropro I think (1) "doesn't fail when used in a monorepo", (2) "supports monorepos", and (3) "includes tools that make working with monorepos easy" are all valid but very different definitions of "monorepo support". Bun currently meets the criteria for (1), sort of meets the criteria for (2), but definitely does not meet the criteria for (3).
As evidenced by @Hebilicious's list (#533 (comment)) and other comments here, there's a lot of work to do before that last criteria is met. Documentation should probably reflect that.
Criteria 1 is not met yet, Bun 1.0 still fails for me when adding packages as described in #3502.
Not sure if it's been flagged yet, but is anyone else having issues running (bun run <script>) package.json scripts from outside of the root of the monorepo? I get a "FileNotFound" with even the simplest scripts.
Not sure if it's been flagged yet, but is anyone else having issues running (
bun run <script>) package.json scripts from outside of the root of the monorepo? I get a "FileNotFound" with even the simplest scripts.
I'm in the same boat. Also, i'm not sure how to run a specific workspace script eg with yarn something like yarn workspace my/ui run build
