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

[mindplay-dk]

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

it's very slow, and the noisy notifications made that very obvious.

it's okay with the notifications muted, I guess.

I don't actually know how slow or fast the original todo-tree is in comparison - but Better Todo Tree feels sluggish.

I might switch back. 🤔

[FanaticPythoner]

Slow...? Sluggish..? Care to explain? @mindplay-dk ? I think you have have gotten something wrong here.

By all rational metrics and evaluated metrics, on all aspects, BTT is orders of magnitude faster, and more memory efficient, while never compromising the main thread and such. The notification you're talking about has been changed based on requests, also.

If you want to compare yourself, there are tons of parity tests in BTT that take the exact Gruntfuggly/todo-tree and compare it side by side with BTT to ensure both features parity and accurate benchmarking for speed in various scenarios as well as memory efficiency / peak RSS in various scenarios as well. You can run those using "just perf" after cloning BTT if you'd like to have confirmation for yourself instead of taking my word for it. You can also see all performance artifacts in artifacts/perf thereafter.

There factually haven't been a single performance issue reported, in fact, people find it way faster, as it factually is. If you have any performance issue, which would be incredibly odd, please open an issue and I'll look into it / fix it within 48h.

[mindplay-dk]

@FanaticPythoner we're off topic and I don't want to create anymore noise here, so I will come to your repo and post some feedback. ☺️