biomejs/biome-vscode

Biome does not find biome executable despite setting lspBin (NixOS)

Closed this issue · 8 comments

I use nixos and I cannot use the binary provided by the npm package. I install https://search.nixos.org/packages?channel=23.11&show=biome&from=0&size=50&sort=relevance&type=packages&query=biome, making it accessible in my $PATH:

$ which biome
/nix/store/rgg2nkfch4n4v4nsnpaq8jxh77xjrnca-biome-1.4.0/bin/biome

However, when I set "biome" as the lspBin, the extension fails to detect it, even though it's available in my VSCode environment. Using "/nix/store/rgg2nkfch4n4v4nsnpaq8jxh77xjrnca-biome-1.4.0/bin/biome" as lspBin resolves the issue, but it's not a sustainable solution due to the volatile nature of the hash in the Nix store. I propose that when lspBin is set to "biome" and biome isn't found in the local directory, it should automatically check in the $PATH as a fallback option.

async function getWorkspaceRelativePath(path: string) {

I believe this method should handle the fallback. But then, the method name should be changed to avoid confusion. Perhaps something like this would work:

import path from 'path'

...

    const pathEnv = process.env.PATH || '';
    const pathDirs = pathEnv.split(path.delimiter);

    for (const dir of pathDirs) {
        const fullPath = path.join(dir, inputPath);
        if (await fileExists(fullPath)) {
            return fullPath;
        }
    }

This would be very misleading, because we explicitly document the option that needs to be a path.

If you set "biome" as value, it means it's possible to set relative paths, which is something that the option doesn't support.

Wouldn't it be better to have an option just for $PATH?

That's also an option. I don't mind any specific implementation as long as it works 😃

This would be very misleading, because we explicitly document the option that needs to be a path.

Does it maybe make sense to change the semantics then? If it’s not a path, but a plain filename, we could check for its presence in PATH. It would be backwards compatible, I believe, and work for more users as expected, without needing any more configuration. But indeed we would need to update the documentation.

From the operating system point of view, whether the file is located in the current working directory, or in PATH, there is no difference in handling it. Many applications also follow this logic. This is the primary reason why we have PATH env in the first place. I believe that unifying the experience will be a good thing. 🙂

I'm going to close this issue in favor of the following task: #127

Feel free to make it known if you'd like to contribute.

Hey! I personally believe it's more of an issue of not supporting $PATH rather than NixOS. The missing $PATH support is not exclusive to NixOS but rather affects all POSIX systems (as per POSIX Programmer's Manual). I believe first-time contributors would be less hesitant to contribute to "Add $PATH env support" rather than "Add NixOS support". 🙂

I've opened #129; let's see if it solves it for you :) !