oven-sh / bun

Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
https://bun.sh
Other
73.51k stars 2.71k forks source link

`bun install` is not recognizing the workspaces anymore #5413

Closed titanve closed 4 months ago

titanve commented 1 year ago

What version of Bun is running?

1.0.1

What platform is your computer?

Darwin 22.6.0 x86_64 i386

What steps can reproduce the bug?

run bun install

What is the expected behavior?

to use workspaces correctly as it was doing yesterday

What do you see instead?

error: package "@company/mypackage" not found npm.pkg.github.com/@company/mypackage 404

Additional information

my workspaces section in package.json file is:

"workspaces": [
    "frontend/mypackage",
    "frontend/myotherpackage",
    "frontend/coolpackage"
  ],

my bunfig.toml file:

[install]
registry = { url = "https://registry.npmjs.org", token ="$NPM_GITHUB_TOKEN" }

[install.scopes]
"@company" = { url = "https://npm.pkg.github.com", token = "$NPM_GITHUB_TOKEN" }
josefaidt commented 1 year ago

I am having this same issue and came close to opening an issue but thought maybe I had done something wrong. This typically happens when I come back to an open project and run bun install. I just have packages/* set for workspaces, and this always seem to affect one specific package:

➜  bun install
[0.17ms] ".env.local"
bun install v1.0.0 (822a00c4)

error: workspace dependency "my-package" not found

Searched in "./*"

Workspace documentation: https://bun.sh/docs/install/workspaces

error: workspace dependency "my-package" not found

Searched in "./*"

Workspace documentation: https://bun.sh/docs/install/workspaces

It's like the lockfile gets clobbered somehow. I'm not sure how to reproduce this either, but as noted this seems to pop up once I come back to an open project.

As a workaround I delete the bun lockfile and reinstall with bun install

elitan commented 1 year ago

I also had issues with this. Deleting the bun.lockb file solved the issue for me.

titanve commented 1 year ago

I can confirm that by doing this (removing the bun.lockb) the issue is solved:

rm -f bun.lockb && bun install
matallui commented 1 year ago

Still finding the same issue on Bun v1.0.2.

Even thought deleting bun.lockb and reinstalling works, it's annoying in my use case. Every time I'm inside my apps/web and run bunx shadcn-ui@latest add component I hit the same issue.

The workaround for me is always to temporary remove the workspace dependencies from apps/web/package.json, then run the shadcn-ui command, then re-add the dependencies, delete bun.lockb and rerun bun install.

paulleonartcalvo commented 1 year ago

Same issue here running 1.0.2. Running install from root appears to work (sometimes I have to delete modules + lock) but doesn't seem to work from within my app when using workspace dependencies.

mathieu-bour commented 1 year ago

Same issue here. I am migrating from pnpm, I was expecting to have a node_modules in each of packages, but I can only see a root node_modules... Maybe it's linked?

paulleonartcalvo commented 1 year ago

I specifically get the workspace dependency x not found when running bun add someDep from within my gui/gui-my-app directory. It only seems to happen when the GUI's dependencies have my design-system package as a dependency.

I don't think the details of my project will be super different from anyone else with this issue, but I'll list them anyway for the sake of clarifying possible causes:

My project structure:

.
├── apps
│   └── gui
│       └── gui-my-app
│           ├── package.json
├── package.json
├── packages
│   └── design-system
│       ├── build.ts
│       ├── index.ts
│       ├── package.json
│       ├── src
│       └── tsconfig.json
├── tsconfig.base.json
└── tsconfig.json

My root package.json has the following:

"workspaces": [
    "packages/*",
    "apps/gui/*"
  ]

My design-system/package.json has the following:

"name": "@myAbitraryProjectPrefix/design-system",
...

And finally my gui/gui-my-app/package.json has the following:

"name": "@myAbitraryProjectPrefix/gui-my-app",
"dependencies": {
...,
"@myAbitraryProjectPrefix/design-system": "workspace:*",
...
}

I don't personally have a ton of experience with workspaces, but I migrated this structure from pnpm where it worked without issues.

OyvindSigvaldsen commented 1 year ago

I am experiencing the same issue using Bun v1.0.2.

jfcieslak commented 1 year ago

Currently, the workspaces resolution implementation seems to be very buggy. The example reffered to in the workspaces guide is not working either. Here are the issues that I found out during experimenting.

  1. Bun uses package version (workspace:*) as a relative path to find a package. That is why it returns this error, because it litereally searches in "./*" relative to where you run the command from:

    error: workspace dependency "my-package" not found
    Searched in "./*"
    Workspace documentation: https://bun.sh/docs/install/workspaces

    Experimenting with versions like: "my-package":"workspace:../*" can work, if you run, for example, a bun add some-npm-pkg command from a matching relative path. But this is of course totally wrong.

  2. Linking packages may resolve correctly If you link all your workspace packages (bun link) then you can refer to them in the version as "my-package":"link:my-package" and it usually works, but then you are not really using workspaces

maxxborer commented 1 year ago

Did this work on previous versions?

paulleonartcalvo commented 1 year ago

Did this work on previous versions?

Not that i know of

rossanmol commented 1 year ago

Experiencing some issue, very unpleasant to work with workspaces atm :(

yentlprojects commented 1 year ago

Did this work on previous versions?

I reverted to 0.8.x and same problems seem to be happening there.

JoltCode commented 1 year ago

Yeah I'm having this issue on the latest bun version too

gabrielmfern commented 1 year ago

can confirm this problem with 1.0.3 as well

medeiroshudson commented 1 year ago

same here. had to perform an rm -f bun.lockb before install

mateusavila commented 1 year ago

For me, only works if I insert the full address of the package:

"dependencies": { "@bun-rpg/zod-validators": "workspace:../../packages/@bun-rpg/zod-validators", }

the workspace is:

{ "name": "bun-rpg", "version": "1.0.0", "type": "module", "private": true, "workspaces": [ "packages/", "apps/" ] }

ricklove commented 1 year ago

This is happening often whenever something changes in any package.json.

But the workaround seems to work each time: rm -f bun.lockb && bun install

Jarred-Sumner commented 1 year ago

@dylan-conway is working on this

prodkt commented 1 year ago

Had time to give bun a spin today on a new project and unfortunately in the first 15 minutes I was also plagued by this. I couldn't overcome it and had to pivot. Looks promising though I'll keep an eye out for when the fix is implemented to give it another shot.

https://github.com/oven-sh/bun/assets/101760605/21ee4388-ea2a-439f-b44d-19a8b6d0cb66

Jarred-Sumner commented 1 year ago

Narrowed down the cause. The code for checking if the package.json has changed is diffing the root package.json compared to the workspace child package.json when the cwd is not the root and it is a reinstall with changes.

There was also a cache invalidation issue in the http client which was fixed a couple days ago.

JoltCode commented 1 year ago

@Jarred-Sumner Please can you confirm if this has now been fixed in Bun v1.0.4? Thanks so much 😄!

Jarred-Sumner commented 1 year ago

@dylan-conway has fixed this in v1.0.4. Please run bun upgrade and leave a comment if you see it still

jfcieslak commented 1 year ago

thx @Jarred-Sumner, it seems to be working as expected now 👌

matallui commented 1 year ago

@Jarred-Sumner I'm still seeing issues with my monorepo, even after recreating the bun.lockb file.

I've made this repo public here.

Just clone it and then:



EDIT: Turns out if I switch the versions of the workspace packages from `*` to `workspace:*` that seems to work. So I guess we can ignore the issue, unless `*` is supposed to be supported as well.
paulleonartcalvo commented 12 months ago

@Jarred-Sumner I'm still seeing issues with my monorepo, even after recreating the bun.lockb file.

I've made this repo public here.

Just clone it and then:

  • bun i
  • cd apps/www
  • bun add tailwindcss-animate
❯ bun add tailwindcss-animate
bun add v1.0.4 (ea956e58)
 🔍 @mono/eslint-config [1/14]
error: package "@mono/eslint-config" not found registry.npmjs.org/@mono%2feslint-config 404
 🔍 @mono/prettier-config [2/14]
error: package "@mono/prettier-config" not found registry.npmjs.org/@mono%2fprettier-config 404
 🔍 @mono/tailwind-config [3/14]
error: package "@mono/tailwind-config" not found registry.npmjs.org/@mono%2ftailwind-config 404
 🔍 @mono/tsconfig [9/17]
error: package "@mono/tsconfig" not found registry.npmjs.org/@mono%2ftsconfig 404
error: @mono/eslint-config@* failed to resolve
error: @mono/prettier-config@* failed to resolve
error: @mono/tailwind-config@* failed to resolve
error: @mono/tsconfig@* failed to resolve

EDIT: Turns out if I switch the versions of the workspace packages from * to workspace:* that seems to work. So I guess we can ignore the issue, unless * is supposed to be supported as well.

This issue was with the docs and was updated some time ago. I believe they have been updated to workspace:* :)

chakrihacker commented 11 months ago

Can we reopen this issue @Jarred-Sumner ??

Jarred-Sumner commented 11 months ago

@chakrihacker please include a reproduction of the issue you’re running into. The original issue here is fixed, so a different one needs a new reproduction for us to fix it

nyxb commented 10 months ago

error still exists in version 1.0.14 you always have to delete the lock file. A fix would be nice. But thanks for the info on how to solve it.

mxvsh commented 10 months ago

@dylan-conway has fixed this in v1.0.4. Please run bun upgrade and leave a comment if you see it still

still same, it doesn't work on version 1.0.14

btakita commented 10 months ago

After upgrading to v1.0.15, I'm unable to install workspace dependencies even after deleting bun.lockb. Downgrading to v1.0.14 fixes the issue.

curl -fsSl https://bun.sh/install | bash -s "bun-v1.0.14"
daedlock commented 9 months ago

Please fix this in HEAD. I also had to downgrade to 1.0.14

goldo commented 9 months ago

I also have the problem (v1.0.16) I think we should re-open it

btakita commented 9 months ago

I fixed my issue by adding the "version" field to package.json

edit

See https://github.com/oven-sh/bun/issues/7433

Also note that you can use other means to install the packages, such as yarn or pnpm.

On Fri, Dec 15, 2023, 6:42 AM Franck Achkouyan @.***> wrote:

I also have the problem (v1.0.16) I think we should re-open it

— Reply to this email directly, view it on GitHub https://github.com/oven-sh/bun/issues/5413#issuecomment-1857745640, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAA4UG5Q6YWLRSOIO6Y4JLYJQZTRAVCNFSM6AAAAAA4Y4XFIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXG42DKNRUGA . You are receiving this because you commented.Message ID: @.***>

CorrM commented 8 months ago

Same for v1.0.22 had to delete bun.lockb

bun install --verbose
bun install v1.0.22 (b400b36c)
Loaded 7 hoisted_dependencies
Loaded 8 resolutions
Loaded 8 dependencies
Loaded 4 extern_strings
Loaded 498 string_bytes
   - "contracts": "packages/contracts" - contracts@workspace:packages/contracts
   - "core": "packages/core" - core@workspace:packages/core
error: workspace dependency "contracts" not found

Searched in "./*"

Workspace documentation: https://bun.sh/docs/install/workspaces
dawsondellavalle commented 8 months ago

I encountered this in v1.0.25.

Using relative paths from the dependent package in its package.json fixed the issue.

"@company/core": "workspace:../core"
DayFlo commented 8 months ago

Also encountered this on v1.0.25.

I changed a package name from packagex to packagey and updated the dependencies only to run bun install getting the error:

error: workspace dependency "@packagey/util" not found

Searched in "./*"

Simple resolution was to find the related dependency in each package.json and update the semver token (^/~/*) to something different with each package name change, which looked like this:

  // package.json
  "name": "api",
  "dependencies": {
      "@packagey/util": "workspace:^",
   }

On the next package name change I would need to go from workspace:^ to workspace:*.

algoflows commented 8 months ago

Same problem for using the latest Bun, been stuck on this for two days as Vercel won't deploy my svelte app as the SvelteKit workspace import of my shared components library won't resolve in CI!!! Two days, trying to get a SvelteKit app deployed. Hope Bun can roll a fix and get workspaces back on track.

algoflows commented 8 months ago

Okay so update on findings. Railway deploys the app fine but Vercel doesn't. My theory is that Vercel is running an older version of Bun without the workspace fix. @Jarred-Sumner

robertherber commented 7 months ago

For us the big problem right now is installing packages in our monorepo:

The two workarounds I see working now:

Neither of them feels really good :)

matallui commented 7 months ago

Yeah, I'm experiencing the same issue as @robertherber

alsa32 commented 7 months ago

Same issue here @robertherber

robertherber commented 7 months ago

We have a new workaround:

#!/usr/bin/env bun
/* eslint-disable no-unused-expressions */
import { $ } from 'bun'

const args = process.argv.slice(2)

await $`bunx add-dependencies ${args.join(' ')}`

await $`bun install`

Feel free to use it through @zemble/utils or copy-paste it into your own project. It uses add-dependencies to just add the entry to the closest package.json without actually installing it and runs a subsequent bun install.

@Jarred-Sumner I think getting this working properly by default is important, I'm guessing this is a biggie for all monorepos.

shoxsz commented 7 months ago

Hello guys, just confirming this issue is still happening, do we have a plan for a fix? it is really frustrating, we could at least update the workspaces page in the docs to notify about this issue, I just lost 1 hour trying to figure this out, really frustrating because all other package managers have this figured out.

tgrushka commented 7 months ago

Wow, this is bad. What the heck? Tell us in the instructions to delete the lockfile, or have a flag to automatically delete it.

Workspaces are very annoying in bun. I love bun except for this. You can't even build a specific subpackage of a monorepo workspace, you have to deploy all of the workspace dependencies to a container.

christian-hackyourshack commented 7 months ago

For this reason I gave up on Bun's workspaces for now, but if I shall consider Bun for production projects this would be a no-go.

btakita commented 7 months ago

To consolidate the issues, I see the following:

issue workaround
Cannot install workspace packages from the cli Add the dependency in package.json instead
Package not found or bin file not added to node_modules/.bin rm bun.lockb && bun i
error: No version matching "..." found for specifier "..." (but package exists) bun pm cache rm && bun i

Other than these issues, each of which has mitigations, bun workspaces seem to work for me. Are there any other issues to make a complete list of issues + workarounds?

To be fair to the Bun team...Bun is a new project making impressive progress. Monorepos are difficult. I have encountered inconveniences but no blocking issues. Other monorepo libraries (like yarn & pnpm) had issues over the years. If these issues make development intolerable, you can use another package manager like pnpm or yarn with bun.

MariuzM commented 7 months ago

O have this working -> https://github.com/MariuzM/bun-workspace

image
Jarred-Sumner commented 7 months ago

We will prioritize fixing this shortly after Bun v1.1

MariuzM commented 7 months ago

Just doing more examples if it helps.

app1 is React Vite - Works fine app2 is React Native Expo - Getting node modules issue. When you start the app it builds fine up to the Simulator screen and even shows the app, but after that getting error. In this case its not looking in root for node_modules but in project.

        throw new UnableToResolveError(
              ^
Error: Unable to resolve module ./node_modules/expo-router/entry from /Volumes/Dev/bun-workspace/apps/app2/.: 

Repo: https://github.com/MariuzM/bun-workspace/tree/main

My testing process:

  1. Nuke all node_modules and *.lock files from all folders.
  2. Run bun install from root
  3. Run bun app1 (works fine)
  4. Run bun app2 (error)