Test: fileSearchProviderNew (new File Search Provider shape)

[andreamah]

Refs #73524

• macOS @jrieken
• linux @justschen
• windows @joshspicer

Complexity: 5
Roles: Developer, Engineering Manager

Create Issue

---

History/Context

FYI: you can skip this part if you already know what's going on with these search APIs.

General

There has been a lot of work going into finalizing 4 search APIs. Here is a little table that soft of explains how they're related, plus the main function calls from each. Essentially, for file and text search, we have to finalize APIs for

1. Leveraging whatever providers (ie: ripgrep) that vscode has access to in order to find text and files (finders).
2. Given that a user is using API or the UI to find text or files, being able to provide results (ie: if someone had a virtual file system, this helps with giving accurate results) (consumers)

findFiles2 is meant to replace the existing finalized API workspace.findFiles. So it will be renamed to findFiles then. It will be added as an overload of the current findFiles call, where the old call signature will be deprecated (but still supported).

Since this is gonna be a huge change for any first-party extensions that are using these proposed APIs, I've split out the new shape in new files that end in New. For example, the new shape for findTextInFiles is in findTextInFilesNew.

fileSearchProviderNew

This TPI focuses on testing the functionality and shape for fileSearchProviderNew

The fileSearchProvider API is meant to be used when you want file search results to be sourced from an extension instead of a simple ripgrep filesystem scan.

Note that a 'file search' is what happens when you do CTRL+P/CMD+P and search for a file in your workspace (but is also done in other places, like when an extension uses an API to find files).

Think about the following scenario: you have a virtual filesystem, so you use the filesystem provider API to show files differently than how it is stored on disk. You would want to use this API to override how search usually works so that it searches the content based on how you are presenting it in the virutal filesystem. This way, results in the quick open (for example) are correct.

Note that this currently only works for resources of an alternate (not file://) scheme.

Set up

Update to the latest Insiders.

Create an extension to test with. To enable the proposed API, use the following in your package.json:

  "enabledApiProposals": [
    "fileSearchProviderNew",
    "fileSearchProvider",
"textSearchProvider"
  ]

and run npx vscode-dts dev to download the proposed API files.

You're going to test fileSearchProviderNew, which is the new shape for TextSearchProvider.

See below for the shape to test:
https://github.com/microsoft/vscode/blob/94f869842859c273491a8067d81f82f5fb30709a/src/vscode-dts/vscode.proposed.fileSearchProviderNew.d.ts

Testing

I like testing this with the existing filesystem provider API sample because it introduces a new URI scheme called memfs:// that I can test with. Note that you can't override how it looks at regular file:// schemes, so if you have a workspace that shows files normally, you can't trigger a custom provider.

• Try implementing a fileSearchProviderNew for memfs://.

vscode.workspace.registerFileSearchProviderNew('memfs', yourProviderInstance)

Where yourProviderInstance is an instance of a class that extends fileSearchProviderNew.

Now, when testing, when you have the memfs filesystem initialized, does your provider work as expected? For example, open the quick open and see whether you can search your memfs workspace as expected.

Also, it'd be great if you could test findFiles and findFiles2 against this API to see if you get your expected results.

If you're feeling extra gutsy, you can even test with the new findFiles2New API (but don't feel too pressured to do this- I have another TPI to test this API in-depth)! :)

Thanks for testing! Please message me if you have any questions! I intentionally left this testing section vague so that I can get a measure of how easy it is to adopt the API.

Known bug

The session option says it is unknown, but really, it still is a CancellationToken. This shouldn't make a difference, but my intention in the future is for the session to be a simple empty JS object. Since a WeakMap will make entries disappear once they object is garbage collected, the empty JS object would disappear from the WeakMap once VS Code stops referencing the object in its internal map. PR: #226687

[jrieken]

the empty JS object would disappear from the WeakMap once VS Code stops referencing the object in its internal map. PR: #226687

Can we make sure #226687 gets merged before the release? Without that early adopters will suffer from leakage and believe the session concept doesn't work

[andreamah]

the empty JS object would disappear from the WeakMap once VS Code stops referencing the object in its internal map. PR: #226687

Can we make sure #226687 gets merged before the release? Without that early adopters will suffer from leakage and believe the session concept doesn't work

@jrieken do you mind providing your review for the PR? The main reason I didn't merge this last night was because I wasn't sure whether this was the correct way to do this.

[justschen]

modified the [fsprovider-sample](https://github.com/microsoft/vscode-extension-samples/tree/main/fsprovider-sample)

works well in empty workspace and multiroot:

was a little confuzzled with setup, then was able to play around with options as well, but overall looks good in terms of how it worked

[joshspicer]

This was my first time reviewing an API test plan item, so it took me a minute to get my bearings. Things seemed to work well, although I ran out of creative testing scenarios quite quickly :')

I also had thoughts related to #226734 as I saw that the API was called on every keypress and made me curious how this would work with a large-latency implementation of provideFileSearchResults. I'm not up with the history that was alluded to in this issue

I opened one issue which is really just a ploy to get you to explain how things work to me :)