feat(cli): Adding an ignore workspace option

[JulesGuesnon]

What does this PR do?

The point of this PR is to add way to ignore the workspace when being in the case of an InstallCommand.
For the context, we have a CLI in our monorepo that is developed with Bun, but we want it to be able to be independent from the monorepo. Since 1.1.7, it'll automatically detect the workspace and go through all the process of installing the workspace dependencies.

This PR adds a new flag --ignore-workspace to bun InstallCommand. When set, it won't go through the workspace detection and run everything for the current package. It also adds the ignoreWorkspace option in the bunfig.toml so you don't have to pass the flag every time.

• Documentation or TypeScript types (it's okay to leave the rest blank in this case)
• Code changes

How did you verify your code works?

I wrote automated tests

• I checked the lifetime of memory allocated to verify it's (1) freed and (2) only freed when it should be
• I included a test for the new code, or an existing test covers it
• JSValue used outside outside of the stack is either wrapped in a JSC.Strong or is JSValueProtect'ed
• I wrote TypeScript/JavaScript tests and they pass locally (bun-debug test test-file-name.test)

[Jarred-Sumner]

The code overall looks good.

Are you sure this is what you want though? This would mean that a workspace bun.lockb may resolve to different versions than the package's bun.lockb.

If package.json in the child package depends on "react": "^18.0", the workspace had used react@18.0.2, but the latest was react@18.0.4, you would end up installing react@18.0.4 instead of react@18.0.2. Both satisfy the semver ^18.0. But often packages don't precisely follow semver, which means that it may cause packages to upgrade that you didn't mean. This can be an issue even if you use exact versions in your dependencies, because your dependencies might not use exact versions themselves.

[JulesGuesnon]

Hey, thanks for the answer!

First about the code, although it looks good, tests are actually failing because of this change:

-            .InstallCommand = false,
-            .AddCommand = false,
-            .RemoveCommand = false,
-            .UpdateCommand = false,
-            .PackageManagerCommand = false,
-            .LinkCommand = false,
-            .UnlinkCommand = false,

I guess it's triggering some undesirable side effects, that's why the PR is still a draft.

About your feedback, I think that would be an "expected behaviour" for every workspace management tool. I mean, from the moment you want a package to be different from everything else, it means that you have to handle a few things by yourself:

• versions
• package resolution through path (if you still need workspace packages)

Also to add more context, even if we're considering using Bun as the workspace management tool, we're still using Yarn to do it. Having Bun that tries to automatically handle the workspace is a problem for now, that's why I thought that being able to disable the workspace detection behaviour would be a good solution. But I guess another one would be to detect if the workspace is already managed by another tool, although it sounds a bit complicated to implement

[KilianB]

Just to give a different perspective as well.
For us this pr would be helpful temporarily when working with a monorepo where one of the packages depends on privately hosted packages on bitbucket as bun install is failing for these. Due to this we also had to revert back to yarn for installation.

While the flag would be helpful in this scenario this is just a bandaid and the real issue should be fixed sooner or later.

[JulesGuesnon]

Hey!
I took my way too much time, but finally found the issue I was looking for!
Had to go through the whole config loading process, but finally found out how it works. All I needed to do was overriding the absolute_working_dir when reading a 2nd time the configuration if we don't ignore the workspace