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

Node 12 ESM reports different errors between editor and CLI #47795

Closed
DanielRosenwasser opened this issue Feb 8, 2022 · 4 comments · Fixed by #47732
Closed

Node 12 ESM reports different errors between editor and CLI #47795

DanielRosenwasser opened this issue Feb 8, 2022 · 4 comments · Fixed by #47732
Assignees
Labels
Fix Available A PR has been opened for this issue Needs Investigation This issue needs a team member to investigate its status.

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 8, 2022

Originally posted by @jaydenseric in #47792 (comment)


I've been using TypeScript v4.6-dev.x and the node12 mode extensively for some time now. One of the things that makes it really confusing to work with the new node12 mode 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 really tsc via 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.6 node12 mode properly with correct package exports, .d.mts files, 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 the tsc CLI 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:

npm run types

In a.mjs:

// @ts-check

/** @typedef {import("playwright").chromium} A */
/** @typedef {import("playwright").Page} B */

In b.mts:

import { chromium } from "playwright";
import type { Page } from "playwright";

In the VS Code editor the imported Page type resolves for intellisense:

Screen Shot 2022-02-08 at 11 12 30 am

Screen Shot 2022-02-08 at 11 12 01 am

But via tsc:

Screen Shot 2022-02-08 at 11 13 01 am

The playwright package 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 @jaydenseric in #47792 (comment)

@jaydenseric
Copy link

jaydenseric commented Feb 8, 2022

A slightly different bug, but another example of the VS Code editor displaying different TypeScript type errors to the tsc CLI: #47796 .

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Feb 8, 2022
@RyanCavanaugh RyanCavanaugh added this to the TypeScript 4.6.1 milestone Feb 8, 2022
@weswigham
Copy link
Member

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, allowJs is set to true - that extends to your node_modules folder. 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 makes Page available as a member of its default export in esm, so you'd want import("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~

@DanielRosenwasser
Copy link
Member Author

I don't have anything to add to that except 😫

@DanielRosenwasser
Copy link
Member Author

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.json Using jsconfig.json
Errors 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fix Available A PR has been opened for this issue Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
5 participants