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.

Sign up for GitHub

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

Jump to bottom

VS Code/language server doesn't properly detect NodeNext module kind based on package.json #47806

Closed
niklashigi opened this issue Feb 8, 2022 · 1 comment · Fixed by #47732
Closed

VS Code/language server doesn't properly detect NodeNext module kind based on package.json #47806

niklashigi opened this issue Feb 8, 2022 · 1 comment · Fixed by #47732
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue

Comments

@niklashigi
Copy link

Bug Report

🔎 Search Terms

  • typescript nodenext errors only reported by tsc
  • typescript nodenext errors not reported by vs code

🕗 Version & Regression Information

I noticed this in 4.6.0-dev.20220208 and didn't try earlier versions because the NodeNext module kind hasn't been included in a stable release yet.

⏯ Playground Link

Can't be reproduced in the Playground.

💻 Code

Reproducing the bug doesn't require specific code, but rather a specific TypeScript and VS Code setup, so I created a reproduction repo. Here's what's necessary to reproduce the issue:

  • Clone the repo
  • Install the dependencies
  • Open the project in VS Code
  • Make VS Code use the workspace TypeScript version (4.6.0-dev.20220208)
  • Compile the code with yarn tsc or npx tsc
  • Open the src/index.ts file in VS Code

🙁 Actual behavior

tsc tells us about the ESM-specific Relative import paths need explicit file extensions... error in src/index.ts while VS Code doesn't. This is likely because tsc correctly detects the file's module kind to be NodeNext based on the package.json while the language server doesn't for some reason.

🙂 Expected behavior

Both tsc and VS Code report the error because they both realize that the file is a NodeNext module.
weswigham added a commit to weswigham/TypeScript that referenced this issue Feb 9, 2022
@weswigham
Add test for microsoft#47806
f615b78
@weswigham weswigham mentioned this issue Feb 9, 2022
Merged
@typescript-bot typescript-bot added the Fix Available A PR has been opened for this issue label Feb 9, 2022
@weswigham
Copy link
Member

Thanks for the succinct test case - I've added it to #47732, which contains the fix to the services resolution cache. (Technically this is probably a dupe of #47795, but this test case is much more contained!)

@weswigham weswigham added the Bug A bug in TypeScript label Feb 9, 2022
weswigham added a commit that referenced this issue Feb 15, 2022
@weswigham @sandersn
Triple-slash reference type directives can override the import mode u…
67172e4 
…sed for their resolution (#47732)

* Triple-slash reference type directives can override the import mode used for their resolution

They now use the file's default mode by default, rather than always using commonjs. The new arguments to the
reference directive look like:

```ts
///<reference types="pkg" resolution-mode="require" />
```

or

```ts
///<reference types="pkg" resolution-mode="import" />
```

* Omit redundant import modes in emitter

* Add test for #47806

* Add server test for triple-slash reference mode overrides

* Move FileReference mode into helper

* Update tests/cases/conformance/node/nodeModulesTripleSlashReferenceModeOverride3.ts

Co-authored-by: Nathan Shively-Sanders <[email protected]>

Co-authored-by: Nathan Shively-Sanders <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug A bug in TypeScript Fix Available A PR has been opened for this issue
Projects
None yet
Milestone
No milestone
3 participants
@weswigham @typescript-bot @niklashigi