Use Yarn workspace

[cometkim]

Solves #7298

Experiment using Yarn workspace instead of #7356

Yarn's advantage:

• Faster
• Cleaner
• Secure
• Sensible, deterministic behavior
• More built-in utilities, e.g:
  • Topological/Recursive command executor
  • Constraints for workspace
  • yarn up @rescript/react "@biomejs/*"

[cometkim]

The "workspace:" protocol helped to create rescript link in the nested node_modules path.

[cknitt]

Personally I like this a lot (big fan of yarn and using it in all our company projects).

Not sure how people not usually using yarn feel about it though. I see you tried the same with npm in #7356, but it was not feasible?

The contributing guide would also need to be updated for yarn.

[cometkim]

Not sure how people not usually using yarn feel about it though. I see you tried the same with npm in #7356, but it was not feasible?

I tried npm first, but the difference in how workspace dependencies are linked had an unintended impact on the docstring tests.

npm doesn't provide any functionality for workspaces other than basic installation, so there is no workaround.

yarn provides more options here, such as workspace: and portal:. It is simple to configure, except for installing yarn CLI, and provides a very stable lockfile format.

[cometkim]

Don't get it. How is it fixed if these completions are still missing?

@cknitt I deleted it intentionally from 93f16ca

Because we don't need the entire API surface to verify the behavior.

[cknitt]

@cknitt I deleted it intentionally from 93f16ca

Ah, got it! 🙂

[cknitt]

Could you also add a CHANGELOG entry?

[cometkim]

Could you also add a CHANGELOG entry?

Done.

Honestly, I'm not sure we should keep verbose logs for not user-facing changes. We do have context in PRs anyway

[cknitt]

Thanks!

Honestly, I'm not sure we should keep verbose logs for not user-facing changes. We do have context in PRs anyway

Certainly not for the small stuff, but I thought this one was a big enough internal change to warrant putting it into the CHANGELOG.