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

Update error messages for CJS imports resolving to ES modules #50088

Merged
merged 7 commits into from
Aug 4, 2022

Conversation

andrewbranch
Copy link
Member

Fixes #50009

@andrewbranch andrewbranch marked this pull request as ready for review July 29, 2022 00:01
@typescript-bot typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels Jul 29, 2022
@@ -191,10 +191,10 @@ tests/cases/conformance/node/index.ts(84,21): error TS2835: Relative import path
// These should _mostly_ work - `import = require` always desugars to require calls, which do have extension and index resolution (but can't load anything that resolves to esm!)
import m24 = require("./");
~~~~
!!! error TS1471: Module './' cannot be imported using this construct. The specifier only resolves to an ES module, which cannot be imported synchronously. Use dynamic import instead.
!!! error TS1471: Module './' cannot be imported using this construct. The specifier only resolves to an ES module, which cannot be imported with 'require'. Use an ECMAScript import instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a bit to convince myself that this worked because I forgot that we allowed import = require in ES modules.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prediction: no user will ever see this error message

Copy link
Member

@DanielRosenwasser DanielRosenwasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't think recommending a dynamic import is very useful, but I think the related info is the big winner here.

I am surprised that we had no(?) tests for an import of an ES module from a .ts file when type: module is unspecified. The related diagnostic only shows up in new tests... But glad we have them now!

Otherwise, I think this is good to go. It's strictly an improvement, and I'll leave it to your judgment whether we want to special-case the no-package.json case.

src/compiler/checker.ts Show resolved Hide resolved
src/services/types.ts Outdated Show resolved Hide resolved
src/compiler/checker.ts Show resolved Hide resolved
sheetalkamat added a commit that referenced this pull request Aug 1, 2022
sheetalkamat added a commit that referenced this pull request Aug 1, 2022
…dits (#50098)

* Add test where module resolution cache is not local and hence doesnt report errors in watch mode

* Ensure module resolution cache is passed through in watch mode

* Remove unnecessary setting of impliedFormat which should anyways be done as part of create source file

* Add test for packge.json changing and modifying implied format

* Distinguish between package.json watch and affecting file location watch

* Pass in failed lookup and affected file locations for source file's implied format
Also stop creating options if we already have them

* Add diagnostic for explaining file's implied format if based on package.json

* Watch implied format dependencies for modules and schedule update on change

* For program if implied node format doesnt match create new source file. Handle implied node format in document registry
Fixes #50086

* Modify tests to show package.json being watched irrespective of folder its in

* Check file path if it can be watched before watching package.json file

* Because we are watching package.json files and failed lookups its safe to invalidate package json entries instead of clearing them out everytime program is created

* Remove todos

* Fix the incorrect merge

* Pickup PackageJsonInfo renames from #50088

* Rename
@andrewbranch
Copy link
Member Author

@sheetalkamat do I still need to cherry-pick some commits into this or did you get those fixes into main?

   ~~~~~~
To convert this file to an ECMAScript module, change its file extension to '.mts' or create a local package.json file with `{ "type": "module" }`.

[12:01:16 AM] Found 6 errors. Watching for file changes.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sheetalkamat this error message seem to be duplicated in tsbuildWatch and tsserver unit tests and I have no idea why—any ideas?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me it seems like for some reason they are not getting de-dupped?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like errors with related info don’t get deduped because the deduping logic tends to happen before attaching the related info, so the diagnostic being added doesn’t appear to be equal to the ones already in the collection yet. I switched to a message chain since related info is better suited for pointing to a different location, but we should maybe look and see if this is happening elsewhere.

@andrewbranch
Copy link
Member Author

I will probably out when Sheetal has a chance to review again—feel free to merge if it looks ok.

@andrewbranch andrewbranch merged commit 7afd14f into microsoft:main Aug 4, 2022
@andrewbranch andrewbranch deleted the bug/50009 branch August 4, 2022 23:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Very confusing message when user doesn't realize they're in a CommonJS context
4 participants