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 no-missing-import getting confused on incremental file changes #338

Merged
merged 1 commit into from
Jan 5, 2024

Conversation

AndrewJakubowicz
Copy link
Contributor

@AndrewJakubowicz AndrewJakubowicz commented Jan 5, 2024

Context

See the following video to preview the issue:

lit-no-import-error.mov

This screen recording captures the integration test created by @benjamind in #335

Fix

This was a rough issue to debug. Ultimately the TypeScript cache seems to sometimes not contain the files required to resolve the module specifier string. The fix is to handle this case by resolving the module specifier without using the cache.

This graceful fallback causes the integration test to pass. I also manually verified that the fix works.

Other changes

I also did a small amount of cleanup removing some commented out code and tiny changes as I had to go pretty deep to find this issue.

Comment on lines +171 to +180
if (result == null) {
// Result could not be found from the cache, try and resolve module without using the
// cache.
result = context.ts.resolveModuleName(
moduleSpecifier,
node.getSourceFile().fileName,
context.program.getCompilerOptions(),
context.ts.createCompilerHost(context.program.getCompilerOptions())
);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This fixes the issue. The rest of the PR is refactor & tests

Copy link
Contributor

Choose a reason for hiding this comment

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

Genius. Nice find.

@@ -285,6 +285,6 @@ export class DefaultLitAnalyzerContext implements LitAnalyzerContext {

// Build a graph of component dependencies
const res = parseDependencies(file, this);
this.dependencyStore.importedComponentDefinitionsInFile.set(file.fileName, res);
this.dependencyStore.absorbComponentDefinitionsForFile(file, res);
Copy link
Collaborator

Choose a reason for hiding this comment

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

What's the difference between these methods?

Copy link
Contributor Author

@AndrewJakubowicz AndrewJakubowicz Jan 5, 2024

Choose a reason for hiding this comment

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

There is no difference except it looked like the intent was that importedComponentDefinitionsInFile should be private, with absorbComponentDefinitionsForFile being the public method to do this logic.

You can see the dependencyStore class defined here: https://github.com/runem/lit-analyzer/pull/338/files#diff-faaba94b3ffda920023b5e0ff3b54f7137199117142a418b7bd79df7e8951c5eR6-R9

This is a pure refactor, no logic change. I can revert this line if it keeps it simpler.

Copy link
Collaborator

@rictic rictic left a comment

Choose a reason for hiding this comment

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

Awesome work!

@rictic rictic merged commit 9f44f6f into runem:master Jan 5, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants