Test: textSearchProviderNew (new Text Search Provider shape)

[andreamah]

Refs #59921

• macOS @ulugbekna
• linux @eleanorjboyd
• windows @roblourens

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.

textSearchProviderNew

This TPI focuses on testing the functionality and shape for textSearchProviderNew

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

Note that a 'text search' is what happens when you do CTRL+SHIFT+F/CMD+SHIFT+F and search for text in your workspace (but is also done in other places, like when an extension uses an API to find text in 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 sidebar search view (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": [
    "textSearchProviderNew",
    "textSearchProvider"
  ]

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

You're going to test textSearchProviderNew, 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.textSearchProviderNew.d.ts

Testing

attn: if you set "search.experimental.closedNotebookRichContentResults": true,, please remove this for this testing (#226859)

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 textSearchProviderNew for memfs://.

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

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

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 findTextInFiles against this API to see if you get your expected results.

If you're feeling extra gutsy, you can even test with the new findTextInFilesNew 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.

[roblourens]

fyi, vscode-dts is deprecated, it's now called @vscode/dts