search

sveltejs / language-tools

The Svelte Language Server, and official extensions which use it
MIT License
1.22k stars 195 forks source link

Error: "Debug Failure. File ... has unknown extension" #1187

Open arggh opened 3 years ago

arggh commented 3 years ago

Describe the bug

Suddenly, after working for a while, Svelte for VS Code stops working. It will still give me options for auto-importing files, but there is no path included in the options and selecting an option doesn't add any imports to the file being edited.

The error shown in the output tab says:

Error: Debug Failure. File ../components/LanguageSelectButton.svelte has unknown extension.

Not sure what the error actually means, but pretty sure the file has a known extension, .svelte.

The output tab content for Svelte Using Svelte v3.43.0 from /Users/arggh/Develop/example/example-foo/node_modules/svelte/compiler Error: Debug Failure. File ../../../../../packages/example-ui/src/LanguageSelect/LanguageSelect.svelte has unknown extension. at Object.extensionFromPath (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:20405:51) at getJSExtensionForFile (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:117454:136) at removeExtensionAndIndexPostFix (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:117447:42) at getLocalModuleSpecifier (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:117000:17) at computeModuleSpecifiers (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:116967:33) at Object.getModuleSpecifiersWithCacheInfo (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:116927:26) at getModuleSpecifiers (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:146057:72) at /Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:146060:26 at Object.flatMap (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:713:25) at getNewImportFixes (/Users/arggh/.vscode-insiders/extensions/svelte.svelte-vscode-105.4.0/node_modules/typescript/lib/typescript.js:146059:28) Using Svelte v3.43.0 from /Users/arggh/Develop/example/node_modules/svelte/compiler SnapshotManager File Statistics: Project files: 0 Svelte files: 204 From node_modules: 309 Total: 729 Using Svelte v3.43.0 from /Users/arggh/Develop/example/node_modules/svelte/compiler

Screenshots

Screenshot 2021-09-29 at 16 12 11

System (please complete the following information):

jasonlyu123 commented 3 years ago

We might need a reproducible for this one. The error is thrown by typescript as shown in the error stack. Typescript's codebase is very complex. Without a reproducible, it's really hard to track down the problem.

jasonlyu123 commented 2 years ago

I guess I have found a reproducible. Can you check if you have the "typescript.preferences.importModuleSpecifierEnding": "js", or "javacript.preferences.importModuleSpecifierEnding": "js", config?

jasonlyu123 commented 2 years ago

It's also possible that the "typescript.preferences.importModuleSpecifierEnding" config is set to auto but there's an existing import in the file that imported with a js file extension like import {} from 'path/to/module.js'. It is quite tricky to fix on our side. I can't find a workaround for all cases.

Guess it would be better we file an issue on the typescript repo to ask if they can remove this debug assertion or not. This might also happen in a lot of tooling for component frameworks with a custom file extension. I tried and it also appears in vetur (for vue). So it might be more beneficial to "fix" on the typescript side.

dummdidumm commented 2 years ago

If the module specified ending is the problem - this might get much more pressing soon, when TS 4.5 is released which brings a ESM mode where module specifier endings are mandatory.