Open chimericdream opened 5 months ago
This definitely seems like a bug - it's probably an issue with the dependency detection logic for --filter
. My hunch is that this is related to scoped packages. Would it be at all possible for you to provide the repository where you encountered this issue?
Unfortunately not. It's in a private ADO repository for my company. I'll try to see if I can approximate it enough to reproduce the issue. It may or may not be today, though.
@gvilums I have created a version of our monorepo with all the company-related bits scooped out (pretty sure). Just to be safe, I made it a private Git repository. Do you mind if I give you access so you can reproduce the bug? I was indeed able to reproduce it consistently with the dummy repo.
Edit: @gvilums I went ahead and added you as a collaborator on the repository where I was able to reproduce this issue.
Thanks @chimericdream, I got the invite. Will look into it.
I have a similar issue with a mono repo / workspace on GCP + Jenkins + Linux + Bun 1.1.6:
Linux gcloud-default-6vvv6a 6.2.0-1019-gcp #21~22.04.1-Ubuntu SMP Thu Nov 16 18:18:34 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
bun run build # works
bun run _build # doesn't work on Linux pkgX not found (but works on Windows)
package.json
"workspaces": [
"packages/*"
],
"scripts": {
"build": "bun build0 && bun build1 && bun build2 && bun build3 && bun build4 && bun build5 && bun build6 && bun build7 && bun build8",
"build0": "bun build0-1 && bun build0-2 && bun build0-3 && bun build0-4 && bun build0-5 && bun build0-6",
"build0-1": "bun --filter 'pkgA' build",
"build0-2": "bun --filter 'pkgB' build",
"build0-3": "bun --filter 'pkgC' build",
"build0-4": "bun --filter 'pkgD' build",
"build0-5": "bun --filter 'pkgE' build",
"build0-6": "bun --filter 'pkgF' build",
"build1": "bun --filter 'pkgG' build",
"build2": "bun --filter 'pkgH' build",
"build3": "bun --filter 'pkgI' build",
"build4": "bun --filter 'pkgJ' build",
"build5": "bun build5-1 && bun build5-2 && bun build5-3",
"build5-1": "bun --filter 'pkgK' build",
"build5-2": "bun --filter 'pkgl' build",
"build5-3": "bun --filter 'pkgm' build",
"build6": "bun build6-1 && bun build6-2",
"build6-1": "bun --filter 'pkgN' build",
"build6-2": "bun --filter 'pkgO' build",
"build7": "bun build7-1 && bun build7-2",
"build7-1": "bun --filter 'pkgP' build",
"build7-2": "bun --filter 'pkgQ' build",
"build8": "bun --filter 'pkgR' build",
"_build": "bun --if-present --filter '*' build",
}
deps
// Round 0
"pkgA"
"pkgB"
"pkgC"
"pkgD"
"pkgE"
"pkgF"
// Round 1
pkgE
"pkgD": "workspace:*",
// Round 2
pkgG
"pkgA": "workspace:*",
"pkgB": "workspace:*",
"pkgC": "workspace:*",
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgF": "workspace:*",
// Round 3
pkgH
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgG": "workspace:*",
// Round 4
pkgI
"pkgA": "workspace:*",
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgG": "workspace:*",
"pkgH": "workspace:*"
// Round 5
pkgJ
"pkgG": "workspace:*",
"pkgH": "workspace:*",
pkgK
"pkgC": "workspace:*",
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgG": "workspace:*",
"pkgH": "workspace:*",
"pkgI": "workspace:*",
pkgL
"pkgC": "workspace:*",
"pkgE": "workspace:*",
"pkgG": "workspace:*",
// Round 5
pkgM
"pkgB": "workspace:*",
"pkgC": "workspace:*",
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgJ": "workspace:*",
"pkgG": "workspace:*",
"pkgH": "workspace:*",
"pkgI": "workspace:*",
pkgN
"pkgF": "workspace:*",
// Round 6
pkgO
"pkgM": "workspace:*",
"pkgB": "workspace:*",
"pkgG": "workspace:*"
pkgP
"pkgM": "workspace:*",
"pkgE": "workspace:*",
"pkgG": "workspace:*",
"pkgH": "workspace:*",
"pkgI": "workspace:*",
pkgQ
"pkgC": "workspace:*",
"pkgD": "workspace:*",
"pkgE": "workspace:*",
"pkgJ": "workspace:*",
"pkgG": "workspace:*",
"pkgH": "workspace:*",
"pkgI": "workspace:*",
// Round 7
pkgR
"pkgO": "workspace:*",
"pkgE": "workspace:*",
"pkgQ": "workspace:*",
"pkgG": "workspace:*",
dev
"pkgN": "workspace:*",
"pkgK": "workspace:*",
@gvilums have you had a chance to dig into this?
I was able to repro the issue but unfortunately haven't had the time to look into this more deeply. I'll update this issue when I get to it
What version of Bun is running?
1.1.4+fbe2fe0c3
What platform is your computer?
Darwin 23.4.0 arm64 arm
What steps can reproduce the bug?
I haven't been able to reproduce this in a trivial repository, so I will break down how our repo is set up. We have a monorepo with workspaces set up in
packages/apps
,packages/services
, andpackages/libraries
. The various packages in the monorepo are as follows:Apps
Services
Libraries
Here is a quick diagram of the relationships between them:
A couple of the packages, most notably the React app, have multiple scripts (including pre- and post- scripts) that get triggered when we run
bun run --filter '@ourscope/*' build
. However, the React app fails to build almost every time because it does not properly wait for the other packages (usually the design system) to finish building. I added a shell script with a 30s pause to the beginning of the React app's build, and that caused everything to build successfully. This leads me to believe that there is a bug in the logic where Bun is keeping track of a given script's dependencies.The storybook package does finish successfully most of the time, but I don't think that is related, as its deps are runtime and not compile-time dependencies.
What is the expected behavior?
All of the scripts, including pre- and post-, for dependencies of a given package finish executing before any pre- or post- scripts of the package itself.
What do you see instead?
The React app usually fails to build because it cannot resolve the dependency to the design system, which has not finished building by the time Bun tries to build the app. If I artificially delay the React app's build, it succeeds.
Additional information
No response