Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bun i in workspaces doesn't symlink local dependencies #4830

Open
Hebilicious opened this issue Sep 10, 2023 · 8 comments
Open

bun i in workspaces doesn't symlink local dependencies #4830

Hebilicious opened this issue Sep 10, 2023 · 8 comments
Assignees
Labels
atw bug Something isn't working bun install Something that relates to the npm-compatible client

Comments

@Hebilicious
Copy link

What version of Bun is running?

1.0.0+822a00c4d508b54f650933a73ca5f4a3af9a7983

What platform is your computer?

Darwin 22.6.0 arm64 arm

What steps can reproduce the bug?

  1. Create a bun workspace with the following config workspaces: ["a", "b"]
  2. Add { dependencies: {a: latest }} to b package.json
  3. Run bun i

Even if A exists locally, bun will fetch the npm version and install it in /b/node_modules/a

What is the expected behavior?

If one package relies on another, you can simply add it as a dependency with bun add. If package b depends on a, bun install will symlink your local packages/a directory into the node_modules folder of b, instead of trying to download it from the npm registry.

I would expect a to be symlinked instead of fetched from npm.

What do you see instead?

The packages are downloaded instead of being symlinked.

Additional information

Please see this repository as a real world example : https://github.com/Hebilicious/form-actions-nuxt/

If you clone it and run bun i, you will see that packages/playgrounds/simple has a node_modules/@hebilicious/form-actions-nuxt instead of a symlink.

This happens whether @hebilicious/form-actions-nuxt is set to latest or to the current version.

@Hebilicious Hebilicious added the bug Something isn't working label Sep 10, 2023
@Hebilicious
Copy link
Author

Hebilicious commented Sep 10, 2023

While this issue is related to latest specifically, it looks very similar to #4650 and #4676

@bndkt
Copy link

bndkt commented Sep 11, 2023

Can confirm, I'm running into the same issue.

@virus2016
Copy link

Same

@nbbaier
Copy link

nbbaier commented Sep 11, 2023

Running into the same issue as well

@bndkt
Copy link

bndkt commented Sep 11, 2023

If you reference the dependency using the workspace protocol (e.g. "my-package": "workspace:*") it works. Notice that you have to delete the bun.lockb and run "bun install" for this to take effect. I sent a PR to fix this in the docs (#4875).

@Hebilicious
Copy link
Author

Hebilicious commented Sep 11, 2023

If you reference the dependency using the workspace protocol (e.g. "my-package": "workspace:*") it works. Notice that you have to delete the bun.lockb and run "bun install" for this to take effect. I sent a PR to fix this in the docs (#4875).

Imo "workspace:*" is a workaround, things should work if you are using latest or the correct version.

@bndkt @nbbaier @virus2016 Please add a 👍🏽 to the first comment, comments like "same" are automatically hidden by GitHub.

@nbbaier
Copy link

nbbaier commented Sep 11, 2023

@bndkt @nbbaier @virus2016 Please add a 👍🏽 to the first comment, comments like "same" are automatically hidden by GitHub.

Done!

@Electroid Electroid added the atw label Sep 14, 2023
@Electroid Electroid added the bun install Something that relates to the npm-compatible client label Oct 2, 2023
@Jarred-Sumner
Copy link
Collaborator

@dylan-conway is this a bug or a documentation issue? if this is a documentation issue, can you update the docs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
atw bug Something isn't working bun install Something that relates to the npm-compatible client
Projects
None yet
Development

No branches or pull requests

7 participants