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

fix autoimports crash: generate namespace and other module symbol imports #60333

Merged
merged 8 commits into from
Nov 1, 2024

Conversation

iisaduan
Copy link
Member

@iisaduan iisaduan commented Oct 23, 2024

MoveToFile, MoveToNewFile, PasteEdits, and related refactors would crash due to autoimports being unable to resolve where module symbols should be imported from.

This PR adds an importAdder function that will generate module imports based off an existing import. The existing import is used as a reference to determine what type of import is generated.

Fixes #58740
Fixes #59240 (comment) (unfortunately original js case still crashes)
Fixes #59284
Fixes #59650
Fixes #59651
Fixes #59701
Fixes #59747

#58897 stops crashing, but the resolution isn't quite correct

Closes #59004
Closes #59447
Closes #60302

Comment on lines +83 to +86
else if (targetSymbol.parent === undefined) {
Debug.assert(declaration !== undefined, "expected module symbol to have a declaration");
importAdder.addImportForModuleSymbol(symbol, isValidTypeOnlyUseSite, declaration);
}
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason why we can't use isExternalModuleSymbol() as a check?

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you mean in the if statement or the debug statement? The debug is needed since the intent of the importAdder function is to copy from an existing declaration

Copy link
Member Author

@iisaduan iisaduan Oct 24, 2024

Choose a reason for hiding this comment

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

For the if statement, namespaces are specifically not external module symbols, so isExternalModuleSymbol wouldn't work if trying to export something that was defined as a namespace (React for example)

@@ -1451,6 +1523,8 @@ export function getImportKind(importingFile: SourceFile | FutureSourceFile, expo
return getExportEqualsImportKind(importingFile, program.getCompilerOptions(), !!forceImportKeyword);
case ExportKind.UMD:
return getUmdImportKind(importingFile, program, !!forceImportKeyword);
case ExportKind.Module:
return ImportKind.Namespace;
Copy link
Member

Choose a reason for hiding this comment

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

I was concerned that there are times this should return ImportKind.CommonJS, but I think the critical cases are already covered by the condition at the top of this function. It’s probably fine.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think cases that should return ImportKind.CommonJs still crash. #60333 (comment)

Fixes #59240 (comment) (unfortunately original js case still crashes)

@iisaduan iisaduan merged commit 3e61718 into microsoft:main Nov 1, 2024
32 checks passed
@iisaduan iisaduan deleted the moveToFile-generateModuleImport branch November 1, 2024 00:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment