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 install doesn't work with workspaces #4628

Closed
giladv opened this issue Sep 8, 2023 · 11 comments
Closed

bun install doesn't work with workspaces #4628

giladv opened this issue Sep 8, 2023 · 11 comments
Labels
bug Something isn't working npm Something that relates to the npm-compatible client

Comments

@giladv
Copy link

giladv commented Sep 8, 2023

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 simple workspaces setup
"workspaces": {
    "packages": [
      "packages/*"
    ]
  }
  1. on packages/package1 do bun init
  2. run bun install from anywhere

What is the expected behavior?

to install deps

What do you see instead?

bun install v1.0.0 (822a00c4)
 + package1@workspace:packages/package1

 1 packages installed [7.00ms]
Failed to install 1 packages
error: Unexpected installing bun-types

Additional information

No response

@giladv giladv added the bug Something isn't working label Sep 8, 2023
@cpreston321
Copy link

Hey @giladv i think the way you setup the workspaces wrong. https://bun.sh/docs/install/workspaces

it should be

{
  "name": "my-project",
  "version": "1.0.0",
  "workspaces": ["packages/*"]
}

@giladv
Copy link
Author

giladv commented Sep 8, 2023

thanks, but still doesn't work with proposed change

@ferdy-roz
Copy link

only works for me for an internal package named @foo/bar in the package.json where I declare a dependency I name it like

"@foo/bar": "workspace:bar"

(as opposed to the docs, saying I should be able to declare a dep by naming it

"@foo/bar": "*"

@joswayski
Copy link

joswayski commented Sep 9, 2023

--- retracting my comment until i can do more testing sorry :$

@giladv
Copy link
Author

giladv commented Sep 9, 2023

just to be clear, the bug i'm mentioning has nothing to do with referring to other workspace packages. the most basic workspace setup does not work currently

@dylang
Copy link
Contributor

dylang commented Sep 9, 2023

I'm seeing this as well. I'm not sure if you are running into the same symptom though.

For me, it's going through the work of installing all dependencies, but only node_modules in the root exists at the end. Workspaces with conflicting versions don't have their own node_modules directories with their specific version of those modules.

My issue is the same as this: #4274

@ferdy-roz
Copy link

my symptoms were that it couldn't resolve dependencies that were in the same monorepo (i.e. one workspace depending on another). i seem to have solved it by simply removing those dependencies altogether from the workspace package.jsons

@Borjagodoy
Copy link

Borjagodoy commented Sep 10, 2023

In my case I think I have the same error as you, I'm doing the example that comes in the bun doc on monorepos using workspaces and the problem comes when calling a component within another, ie stuff-a as a dependency of stuff-b, there is no way to detect it. I think it is for lack of scope ... believe that the issue is the same as this one

#3806

[EDIT]: Feel like if you import the dependencie in stuff-b as "dependencies": { "stuff-a": "workspace:*"} works the bun install, but persist the problem when you do a bun add

@Electroid Electroid added the npm Something that relates to the npm-compatible client label Oct 27, 2023
@Jarred-Sumner
Copy link
Collaborator

This specific scenario no longer occurs, most likely as of a few versions ago but certainly at least on Bun v1.0.11
image

@quantizor
Copy link

quantizor commented Dec 20, 2023

@Jarred-Sumner this is still broken, you can see it in action for styled-components in this PR styled-components/styled-components#3959

packages/styled-components should use react 17 and packages/sandbox should use react 18

if you run bun run test you'll see all the failures from the mismatching React version that don't exist in trunk when they were consistent

@quantizor
Copy link

Opened a new issue #7791

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

No branches or pull requests

9 participants