Repository navigation
Node 12 ESM reports different errors between editor and CLI #47795
Description
Activity
A slightly different bug, but another example of the VS Code editor displaying different TypeScript type errors to the
tscCLI: #47796 .Wooooooo, so this is a weird one. First off, playwright. Playwright doesn't have it's esm entrypoint explicitly typed (only its cjs entrypoint). So what're you getting, then? Since you're working with a
jsconfig.json,allowJsis set totrue- that extends to yournode_modulesfolder. So you're loading playwright's actual JS files (which mostly just reexport things from other packages at the top level!) - this actually works out pretty well on the command line, as we correctly identify that playwright's esm entrypoint makesPageavailable as a member of its default export in esm, so you'd wantimport("playwright").default.Page. So why, then, is the editor doing differently? Ah, well. There's a bug in how caching is done in the language service, it seems, and the editor is mistakenly loading the cjs entrypoint. By pure chance, the rejiggering of that cache done in #47732 to handle modal triple slash references fixes the problem~Reacted by Jayden Seric, Ryan Cavanaugh and Andrew BranchI don't have anything to add to that except 😫
Wait, I guess I do.
If you use a
jsconfig.json, you can see that on the command line you'll get errors.However, if you switch to a
tsconfig.json, it goes back to working again!So it's very weird.
x Using tsconfig.jsonUsing jsconfig.jsonErrors in Command Line No Yes Errors in Editor No No Based on what you said, I would expect errors in both the CLI and editor scenarios for
tsconfig.json.
Originally posted by Jayden Seric (@jaydenseric) in #47792 (comment)
I've been using TypeScript v4.6-dev.x and the
node12mode extensively for some time now. One of the things that makes it really confusing to work with the newnode12mode is that often VS Code lies and is able to display types for imports ok within the editor (yes, with the local TypeScript installation selected in VS Code), when reallytscvia the CLI can't resolve the types. You will see "has no exported member" type errors for the same imports, when the imported package doesn't support TypeScript v4.6node12mode properly with correct packageexports,.d.mtsfiles, etc.It makes it harder to evaluate as you are working what packages are ESM ready and to experiment with possible fixes for a PR by hacking them in
node_modules, since you have to ignore what the editor is saying and keep running thetscCLI for feedback.An example of a package this happens with is
playwright@1.18.1...With this
.vscode/settings.json:{ "typescript.disableAutomaticTypeAcquisition": true, "typescript.enablePromptUseWorkspaceTsdk": true, "typescript.tsdk": "node_modules/typescript/lib" }And this
jsconfig.json:{ "compilerOptions": { "module": "node12", "noEmit": true, "strict": true }, "typeAcquisition": { "enable": false } }And this package
devDependency:{ "typescript": "^4.6.0-dev.20220207" }And this package
scripts:{ "types": "tsc -p jsconfig.json", }If you run:
In
a.mjs:In
b.mts:In the VS Code editor the imported
Pagetype resolves for intellisense:But via
tsc:The
playwrightpackage doesn't appear to be in the list of "popular" packages for this issue, but given it's pretty popular and also a Microsoft project that aims to support TypeScript it would really make sense for it to be fully compatible with TypeScript v4.6.Originally posted by Jayden Seric (@jaydenseric) in #47792 (comment)