build(schema): Add '$schema' property#4623
Conversation
|
I have thought about this previously. Pretty useful for autocompleting fields in Neovim, VSCode etc. |
|
Why define a |
@niheaven Will warn "$schema property not allow here" by VSCode if use this schema explicitly. |
|
Err, what is the situation of using this schema explicitly? In bucket's |
It can help in code autocompletion, and warn about unsupported fields right there in the text editor, which can save time. It's optional anyway, so won't break anything.
Well, not everyone uses VSCode 😉
It is the standard practice. Look at Windows Terminal's settings schema, for example: https://raw.githubusercontent.com/microsoft/terminal/release-1.11/doc/cascadia/profiles.schema.json. When you install Windows Terminal for the first time, the settings file already contains these 2 fields: This helps in easy discoverability of supported features and fields. |
|
Setting config file that used Please modify the title and add changelog item for this PR. |
@niheaven I make this PR from master branch, so I can't modify the changelog. Maybe you can help me modify it? |
|
Your PR is just 4 line change, you can close this and create new one from |
|
Aha, got it. But you need to revert the recent two commits after this PR is merged in your forked repo. |
| - **decompress:** Fix nested Zstd archive extraction ([#4608](https://github.com/ScoopInstaller/Scoop/issues/4608)) | ||
| - **shim:** Fix PS1 shim error when in different drive in PS7 ([#4614](https://github.com/ScoopInstaller/Scoop/issues/4614)) | ||
|
|
||
| ### Builds |
There was a problem hiding this comment.
Is Builds the appropriate category here? I'm not so sure.
There was a problem hiding this comment.
I put all schema and bin changes under Builds since this has less CLI changes to end users.

Description
schema.json should allow $schema property
Checklist: