Nova and the Deno language server use different syntax identifiers for the same things:
jsx vs javascriptreact
tsx vs typescriptreact
The Deno identifiers, although uglier (since JSX is not limited to React projects), seem to be the most conventional as they are the same as VS Code uses.
When creating a new Nova LanguageClient, the constructor accepts a syntaxes array in the client options parameter:
This API design assumes both Nova and the language server use the same identifier for the same syntax. Instead of an array of syntaxes, perhaps the API should be changed to an object with keys and values that map Nova syntax IDs to language server IDs.
In the meantime, what is the workaround? I’m blocked from getting Deno linting, etc. working in .jsx and .tsx files.
It seems that correct term from the language server spec (in the table below TextDocumentItem) is typescriptreact. But at the same time @apexskier’s TypeScript extension is using tsx (link). Have you tried using both or different combinations as a workaround?
My guess would be Nova internally uses that value to know what documents a LanguageServer applies to. So as long as it matches what Nova is expecting it should work and an unknown (to Nova) identifier would mean text documents aren’t synchronised with the LanguageServer and nothing would happen (ie no linting errors)
@robb-j using the non-standard jsx or tsx syntax specifiers with the Deno language server results in an initialization error. Some LSP functionality might still work despite the error, but that’s due to a Deno LSP possible bug where it continues to process the document despite the unrecognized syntax, and this behavior can’t be relied upon as Deno makes improvements. Have a read of this Deno issue.
Since there’s been no reply here from the Nova team after 12 days, I went ahead and published my Deno extension without support for JSX and TSX syntax; here’s the issue to track. I really hope this problem can be solved properly sometime soon!