Add lookup path for @vscode/ripgrep-universal

[LazarusX]

Summary

VS Code 1.122 moved the bundled ripgrep binary from @vscode/ripgrep to @vscode/ripgrep-universal with platform-specific subdirectories (e.g. bin/darwin-arm64/rg, bin/linux-x64/rg).

This causes the extension to fail with:

Todo-Tree: Failed to find vscode-ripgrep - please install ripgrep manually and set 'todo-tree.ripgrep.ripgrep' to point to the executable

Fixes #925. Fixes #926.

Changes

• Add lookup paths for node_modules/@vscode/ripgrep-universal/bin/<platform>-<arch>/rg and the .asar.unpacked variant
• Fix the setting name in the error message (todo-tree.ripgrep → todo-tree.ripgrep.ripgrep)

Tested

Verified on macOS (VS Code 1.122) that the binary exists at:

<appRoot>/node_modules/@vscode/ripgrep-universal/bin/darwin-arm64/rg

Also confirmed working on Windows and Linux by @ForeverACE (see comment).

[ForeverACE]

FWIW, I'm able to confirm on my Windows 11 PC and GNU/Linux PC that, at minimum, the portion of the fix below will work for VSCode version 1.122.0. I'm unable to test the other case but it likely would work as well.

var platformArch = process.platform + "-" + process.arch;

rgPath = exePathIsDefined( path.join( vscode.env.appRoot, "node_modules/@vscode/ripgrep-universal/bin/", platformArch, exeName() ) );
if( rgPath ) return rgPath;

Paths:

• Linux: <program_path>/resources/app/node_modules/@vscode/ripgrep-universal/bin/linux-x64/rg
• Windows: <program_path>\resources\app\node_modules@vscode\ripgrep-universal\bin\win32-x64\rg.exe

One minor suggestion would be to change it from var platformArch to const platformArch but VERY minor.

[LazarusX]

Thanks for confirming on Windows and Linux! Good to know the paths match across all three platforms.

Regarding const — agreed it would be better in general, but the existing codebase uses var throughout so I kept it consistent with the surrounding style.

[mindplay-dk]

might be clearer as a loop at this point

const appRoot = vscode.env.appRoot;
const exe = exeName();
const platformArch = process.platform + "-" + process.arch;

const candidates = [
    vscode.workspace.getConfiguration('todo-tree.ripgrep').ripgrep,
    path.join(appRoot, "node_modules/vscode-ripgrep/bin/", exe),
    path.join(appRoot, "node_modules.asar.unpacked/vscode-ripgrep/bin/", exe),
    path.join(appRoot, "node_modules/@vscode/ripgrep/bin/", exe),
    path.join(appRoot, "node_modules.asar.unpacked/@vscode/ripgrep/bin/", exe),
    path.join(appRoot, "node_modules/@vscode/ripgrep-universal/bin/", platformArch, exe),
    path.join(appRoot, "node_modules.asar.unpacked/@vscode/ripgrep-universal/bin/", platformArch, exe),
];

for( const candidate of candidates )
{
    const rgPath = exePathIsDefined( candidate );
    if( rgPath ) return rgPath;
}

</bikeshedding> 🙃

[ForeverACE]

Thanks for confirming on Windows and Linux! Good to know the paths match across all three platforms.

Regarding const — agreed it would be better in general, but the existing codebase uses var throughout so I kept it consistent with the surrounding style.

I totally agree that keeping the same coding style is the best practice and the recommended changes follow, IMO, best practices. I try to do the same when making small changes but, I also like to look for opportunities to make minor improvements when I modify a function to clean up legacy code. Although not necessary, I think the suggestion from @mindplay-dk is a great refactor which addresses the previous repeated duplicate code.

Edit: Just a quick FYI, given that this project seems like it may no longer be maintained, I've started looking at forks of this repo for alternatives and I think some of these others could benefit from this pull request too. I don't know what the rules are here so I won't mention one specific but there's a recently updated one that seems to be a good candidate which has significant speed improvements.

[FanaticPythoner]

@LazarusX @ForeverACE @mindplay-dk See: FanaticPythoner#22

[AaronMingCN]

is there any env var to locate dyn?

[ForeverACE]

@LazarusX @ForeverACE @mindplay-dk See: FanaticPythoner#22

Yours was the repo I was looking at - I wasn't sure what the rules were/are for linking to another repo but I'd be happy if your becomes the defacto replacement. It seems pretty good so far :D

[ForeverACE]

is there any env var to locate dyn?

I may be daft but I think you're asking if there's an environment variable that can be used. As far as I've been able to find, no. The reason the extension needs to do this look up is because the developers of VSCode didn't intend for their own libraries to be used by the extensions. I believe there was even a comment by a Microsoft developer from a few years ago that they, essentially, didn't care about maintaining the path structure because only VSCode should be using it.

Hopefully this addresses your question. If not, just ignore my confused response ;)

[MurtadhaInit]

I saw the last commit in this project was 3 years ago, is the project still being actively worked on? i.e. is the PR going to be merged (assuming it's ready)?

[karakarasuuuu]

switched to the repo mentioned above and it worked like a charm