This took a while to nail down, but we had an issue where a TS file was created in the utf16le encoding. This can happen when using pipes in PowerShell commands, so not a total edge case.
Volar fails to parse the file with a "file is not a module" error. The default TS language server can parse the same file correctly, which can even hide this error from view if Volar is not used in takeover mode. The error goes away in VSC if you open the file in a tab, and comes back if you close the tab. I assume VSC is able to parse the encoding correctly, and Volar uses the editor's copy of the parsed file where possible.
Reproduce the error by taking any ts file and re-encoding it into utf16le.
Our workaround is to document the issue and yell at anyone committing non-utf8 encoded files, so not a blocker 🤷♂️
This took a while to nail down, but we had an issue where a TS file was created in the utf16le encoding. This can happen when using pipes in PowerShell commands, so not a total edge case.
Volar fails to parse the file with a "file is not a module" error. The default TS language server can parse the same file correctly, which can even hide this error from view if Volar is not used in takeover mode. The error goes away in VSC if you open the file in a tab, and comes back if you close the tab. I assume VSC is able to parse the encoding correctly, and Volar uses the editor's copy of the parsed file where possible.
Reproduce the error by taking any ts file and re-encoding it into utf16le.
Our workaround is to document the issue and yell at anyone committing non-utf8 encoded files, so not a blocker 🤷♂️