Skip to content

Fix auto imports in JS files in nodenext #54817

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

Merged
merged 1 commit into from
Jun 28, 2023
Merged

Fix auto imports in JS files in nodenext #54817

merged 1 commit into from
Jun 28, 2023

Conversation

andrewbranch
Copy link
Member

Fixes #54350

@typescript-bot typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels Jun 28, 2023
Comment on lines +16 to +17
// @Filename: /totally-irrelevant-no-way-this-changes-things-right.js
//// export default 0;
Copy link
Member Author

Choose a reason for hiding this comment

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

We were using the presence of ES module syntax in other files as an indicator of what to use, but --module nodenext is a stronger signal—we should default to syntax that won’t crash in Node.

@andrewbranch andrewbranch merged commit c97e4b6 into main Jun 28, 2023
@andrewbranch andrewbranch deleted the bug/54350 branch June 28, 2023 22:03
if (sourceFile.impliedNodeFormat === ModuleKind.CommonJS) return true;
if (sourceFile.impliedNodeFormat === ModuleKind.ESNext) return false;

// 5. Match the first other JS file in the program that's unambiguously CJS or ESM
for (const otherFile of program.getSourceFiles()) {
if (otherFile === sourceFile || !isSourceFileJS(otherFile) || program.isSourceFileFromExternalLibrary(otherFile)) continue;
if (otherFile.commonJsModuleIndicator && !otherFile.externalModuleIndicator) return true;
if (otherFile.externalModuleIndicator && !otherFile.commonJsModuleIndicator) return false;
Copy link
Member

Choose a reason for hiding this comment

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

when checking with other file, would it be better to check their implied node format as well to determine what this file probably is supposed to be.

Copy link
Member Author

@andrewbranch andrewbranch Jun 28, 2023

Choose a reason for hiding this comment

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

Because of the new checks I added, all files in the program are guaranteed to have an undefined impliedNodeFormat at this point in the code. impliedNodeFormat is always set to one of the two options I checked for, or else it’s not used at all in the program’s module mode.

Copy link
Member

Choose a reason for hiding this comment

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

Isnt it set by looking up package.json in ancestor directory so is it not possible to have impliedNodeFormat not set on one file vs other ?

Copy link
Member Author

Choose a reason for hiding this comment

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

If no package.json is found, it defaults to CJS. (This reflect’s Node’s behavior too. The choice is binary; the field is only optional because it’s not used outside of --module nodenext.)

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.

Auto import suggests ES imports in JS file that uses CommonJS
4 participants