🐛 IntelliJ Plugin: Crash on v0.0.5 after upgrading from v0.0.3 w/ Yarn PnP

[Joshuabaker2]

Environment information

CLI:
  Version:                      1.2.2
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v18.18.2"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    false
  VCS disabled:                 true

Workspace:
  Open Documents:               0

Discovering running Biome servers...

Server:
  Status:                       stopped


yarn --version
4.0.0-rc.31

What happened?

1. Updated Biome IntelliJ plugin to 0.0.5 from 0.0.3 (where it was working).
2. Got a crash:

  Unhandled exception in [CoroutineName(ProjectImpl), StandaloneCoroutine{Cancelling}@8b25eb1, Dispatchers.Default]
  
  com.intellij.execution.ExecutionException: Specify a valid package manager: cannot find a binary file inside '/usr/local/bin/yarn' directory
at com.intellij.javascript.nodejs.npm.NpmUtil.findBinCliFile(NpmUtil.java:178)
at com.intellij.javascript.nodejs.npm.NpmUtil.getValidNpmCliJsFilePath(NpmUtil.java:103)
at com.intellij.javascript.nodejs.interpreter.NodeCommandLineConfigurator.configure(NodeCommandLineConfigurator.java:37)
at com.github.biomejs.intellijbiome.BiomeUtils.createNodeCommandLine(BiomeUtils.kt:69)
at com.github.biomejs.intellijbiome.BiomeUtils.getBiomeVersion(BiomeUtils.kt:31)
at com.github.biomejs.intellijbiome.widgets.BiomeWidget.getSelectedValue$lambda$0(BiomeWidget.kt:55)
at com.intellij.openapi.progress.impl.CoreProgressManager$1.run(CoreProgressManager.java:252)
at com.intellij.openapi.progress.impl.CoreProgressManager.startTask(CoreProgressManager.java:428)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.startTask(ProgressManagerImpl.java:115)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcessWithProgressSynchronously$9(CoreProgressManager.java:512)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$new$0(ProgressRunner.java:87)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$4(ProgressRunner.java:251)
at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:71)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:186)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$13(CoreProgressManager.java:604)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:679)
at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:635)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:603)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:61)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:173)
at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:71)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$submit$5(ProgressRunner.java:251)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$18(ProgressRunner.java:465)
at com.intellij.openapi.progress.impl.ProgressRunner.lambda$launchTask$19(ProgressRunner.java:477)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
at java.base/java.lang.Thread.run(Thread.java:833)
Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [CoroutineName(ProjectImpl), StandaloneCoroutine{Cancelled}@8b25eb1, Dispatchers.Default]

Expected result

I'm guessing there was some check that changed that checks where the package manager is installed and it is expecting the yarn path to be a directory rather than the yarn binary itself.

For reference,

> which yarn
/usr/local/bin/yarn

I'm not even sure why it's checking for yarn at all though, as I have installed biome globally using bun, so I set the "Biome CLI Path" to that: <userdir>/.bun/bin/biome.

Code of Conduct

• I agree to follow Biome's Code of Conduct

[ematipico]

Yes, we changed how we check for the binary. Now the plugin looks for node_modules/bin/biome, that's why it doesn't work anymore.

Also, we usually advise against installing Biome globally.

@victor-teles do you think we can add a configuration where the users can set the path to their own binary? Or is it already there?

[victor-teles]

@Joshuabaker2

Can you check your node interpreter configuration?
The package manager settings seems to point to the yarn binary, it's need to be the directory of yarn.

https://www.jetbrains.com/help/webstorm/installing-and-removing-external-software-using-node-package-manager.html#ws_npm_yarn_configure_package_manager

[Joshuabaker2]

Yeah @victor-teles it's currently set correctly based on what's available on the dropdown.

And @ematipico there is indeed a spot where the binary path can be set, I'm guessing this is what changed?

[Joshuabaker2]

Put up a fix at #601, tested it and it works locally.