Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON Schema (still) not applied for custom file extension #790

Open
1 of 4 tasks
demilsson opened this issue Oct 5, 2022 · 4 comments · May be fixed by #805
Open
1 of 4 tasks

JSON Schema (still) not applied for custom file extension #790

demilsson opened this issue Oct 5, 2022 · 4 comments · May be fixed by #805
Assignees
Labels
Milestone

Comments

@demilsson
Copy link

Describe the bug

This has been reported previously, in issues:

And was fixed in PR #714

However, I'm still experiencing the issue.

I believe I can spot the error:

When it adds the custom file extensions to the yamlSettings.fileExtensions array, it pushes the entire pattern. This pattern most often has an asterisk in it, like *.bu. It then checks to see if the extension is present in the fileMatch property of the schema. The problem is that it does an indexOf of the pattern on the fileMatch string, which means it includes the asterisk when looking at the file.

So, I think a solution would be to remove the asterisk before searching for it in the fileMatch properties.

However, I'm a bit confused as to why the test passes...

Expected Behavior

YAML schemas are applied on files with custom extensions if they are configured in the files.associations array to be associated with YAML.

Current Behavior

YAML schemas are not applied on files with custom extensions.

Steps to Reproduce

See referenced issues.

Environment

  • Windows
  • Mac
  • Linux
  • other (please specify)
@gorkem gorkem added the bug label Nov 18, 2022
@gorkem
Copy link
Collaborator

gorkem commented Nov 18, 2022

Is this the case when the fileExtension and the fileMatch are not identical? The string matching is too simple for that case and we should do a glob match.

@msivasubramaniaan msivasubramaniaan self-assigned this Nov 28, 2022
@msivasubramaniaan msivasubramaniaan added this to the 1.11.0 milestone Nov 28, 2022
@msivasubramaniaan msivasubramaniaan linked a pull request Nov 28, 2022 that will close this issue
@sam-mccall
Copy link

sam-mccall commented Dec 29, 2022

I'm puzzled by the behavior here. If I've opened a file and:

  • my editor tells yaml-language-server that the file is open, the language is YAML and the filename is foo.bar
  • schemastore says that files named "*.bar" have schema XYZ

...then why isn't that enough to use that schema?
Why is yaml-language-server filtering out schemastore FileMatch patterns based on trying to reason about file extensions, when LSP says it's up to the editor to decide whether a file is YAML?

Apart from the specific issues about globs etc, this scheme seems like it won't work when:

  • I've just manually set the language to YAML in the editor (in the status bar in vscode, or :set ft=yaml in vim, etc)
  • I'm using a non-VSCode editor (the files.associations setting is not specified in LSP, it's a VSCode-specific setting and other editors will not return anything).

@gorkem
Copy link
Collaborator

gorkem commented Jan 3, 2023

yaml-language-server creates an index of schemas it needs to know about using files.associations. We could improve the behaviour by adding incremental indexing on didOpen.

Unfortunately, we are not staffed to test/implement the LSP on editors other than VSCode, so such oversights happen.

@msivasubramaniaan msivasubramaniaan modified the milestones: 1.11.0, 1.12.0 Feb 14, 2023
@demilsson
Copy link
Author

Is there any update on this issue? I see it was part of the 1.12 milestone but seems to have been a little lost.

I'd argue that it's quite a useful issue to fix, not only for our own use case but also for all the other uses of custom file extensions, most notably dotfiles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants