Reduce Preference Validation Warnings & Improve Monaco Extractor

[colin-grant-work]

What it does

This PR reduces the number of warnings logged by the PreferenceValidationService (hopefully to 0, unless real problems are created by user entry) by improving preference extraction from Monaco and adjusting a few schemata to reflect additional values expected by Monaco but not explicitly specified in the schema.

How to test

1. Open a workspace. Remove any custom preference settings.
2. Open an editor.
3. Observe that no warnings are logged by the preference validation system about preference values differing from the schema.
4. Set a preference to a disallowed value (e.g. a editor.fontSize or editor.tabSize to a string or something else silly)
5. Observe that a warning is logged and the value does not take effect.
6. Check that setting the preferences whose interface values have been changed reflects the values correctly

E.g. that the options for editor.unicodeHighlight.includeComments really are true, false (booleans, not strings) and 'inUntrustedWorkspace'

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

After the changes I still get a single warning for the eslint preferences (?):

root WARN A contributed preference schema has validation issues : data.properties['eslint.workingDirectories'].items.anyOf[1].properties['default'] should be object,boolean, data.properties['eslint.workingDirectories'].items should be array, data.properties['eslint.workingDirectories'].items should match some schema in anyOf

Also, when changing a preference to an invalid value, such as "files.autoSave": true, the UI seems to display a changed value:

It seems like this value isn't applied as expected, since auto save is still enabled, even though the UI displays off.

[colin-grant-work]

@msujew thanks for taking a look. Both of those behaviors are expected. The validations warnings I want to limit are at preference read time and say something about substituting a valid value for an invalid value.

• the ESLint preference warning occurs at contribution read time, and originates from the schema contribution. It is worth checking whether the warning is our fault for not expecting the right schemas or ESLint's for some kind of formatting error, but it's beyond the scope of this PR.
• The markings of modified preferences reflect differences between the JSON and default, whether or not we're using what's in the JSON. VSCode has the same behavior, where a modified preference is marked even if the value is garbage (literally), but the default is still shown in the UI. I'm not exactly sure what should be shown for enum preferences if you write an incorrect value in the JSON - they're designed only to display the options they're aware of, but it's true that the user could do whatever they want in the JSON. Do you have any intuition about what you'd like to see in the UI in that scenario?

[msujew]

the ESLint preference warning occurs at contribution read time, and originates from the schema contribution. It is worth checking whether the warning is our fault for not expecting the right schemas or ESLint's for some kind of formatting error, but it's beyond the scope of this PR.

@colin-grant-work Alright, that's good to know, I was just following the Observe that no warnings are logged by the preference validation system about preference values differing from the schema. testing step :)

VSCode has the same behavior, where a modified preference is marked even if the value is garbage (literally), but the default is still shown in the UI.

Right, I didn't explain myself well enough. I'm not complaining that the preference is marked as modified (it's modified, so it's the expected behavior), the issue is that afterDelay is actually the default in the browser app, which I've tested. Adding "garbage" sets the selected preference value in the frontend to off, although the actual preference value is still afterDelay. So there's some disconnect in what the UI shows and what's actually selected by the application. I believe enum rendering uses 0 as a fallback value, but it should probably use the default value as its fallback.

[msujew]

Changes are looking good to me!

• No unexpected preference validation warning errors on startup
• Invalid preference values are logged out as such
• The preference UI continues to show the preference values in effect