Wire SchemaStore catalog matching as $schema fallback

[srivastava-diya]

Description

This PR wires the SchemaStore catalog matching (getSchemaUri) into JsonDocument as a fallback for documents that don't have an $schema field e.g. package.json, tsconfig.json etc.

Changes made

• validate() always calls validateSchema() now, regardless of whether $schema is present
• validateSchema() checks this.schemaUri first if set, validates immediately. If not, it falls back to schemaStore.getSchemaUri(this.uri), which matches the document's filename against the SchemaStore catalog.
• The result is assigned to this.schemaErrors synchronously as a Promise for callers like SchemaValidation

[jdesrosiers]

Looks pretty good so far. It could use a little cleanup and we're going to have to something more for the file matching logic (details inline).

[jdesrosiers]

I added a Workspace service to handle determining the workspace folders. Since we have a Workspace service now, I thought it would be best to move the workspace changed handling to there as well.

I also changed the SchemaStore tests to test at the application boundaries and updated the TestClient to support mocking http requests and to block any http requests that aren't mocked.

[jdesrosiers]

Looks good. I just did a little promise management cleanup and add a few tests.

[jdesrosiers]

Looks like there are file pattern matching tests failing on Windows. My understanding is that picomatch is supposed to handle OS path differences automatically. See if you can get that working.

[srivastava-diya]

My understanding is that picomatch is supposed to handle OS path differences automatically. See if you can get that working.

sure, looking into it.

[jdesrosiers]

I noticed that validation could happen before the catalog starts loading resulting in the documents that use the catalog not getting validated correctly. I updated it to create the promise immediately using the same trick we use in tests to capture diagnostics.

If your load tests seem to still be working, go ahead and merge when ready.

[srivastava-diya]

If your load tests seem to still be working, go ahead and merge when ready.

um so i tried testing this on the extension development host and noticed the fix that has been applied so that validation happens only after catalog loads works perfectly, as intended.

[srivastava-diya]

But we have an issue here

if (isMatch(path.relative(workspacePath, filePath), pattern, { windows: true })) {

here we are finding the path RELATIVE to the workspace rroot. So for that file at vscode-extension-samples/source-control-sample/package.json, as our workspace root is vscode-extension-samples, the relative path is
source-control-sample/package.json but package.json has a file match pattern something like this "fileMatch": ["package.json"] so picomatch returns false and no schema validation takes place.

but before i jump to any conclusion i wanted to ask like if that is intended? like should we only validate files in our root? or do we also want to validate files that match by filename anywhere in the workspace even nested?

[jdesrosiers]

should we only validate files in our root? or do we also want to validate files that match by filename anywhere in the workspace even nested?

I was thinking that you would need to use **/whatever.json to match anywhere in the path rather than from the root. There examples of this in the catalog. There shouldn't be any need to do that if it's supposed to match anywhere in the path.

But, those examples are so rare, I'm not sure it's actually necessary. I can't find anywhere it's documented one way or another what the intention is. Given the package.json example, I know people will expect it to match anywhere, so let's stick with that interpretation for now.

I think there's a picomatch config that would easily allow us to change the behavior. We should also update the tests that assume the interpretation that it matches from the root.