-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat(trace): resolve incorrect extension #9486
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Skipped Deployments
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two small questions
let type_package = format!("@types/{}", import); | ||
let resolved_type_import = resolver | ||
.resolve(file_path, type_package.as_str()) | ||
if !import.starts_with(".") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a check against ./
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I don't think packages can start with .
?
} | ||
|
||
// Also try without the extension just in case the wrong extension is used | ||
let without_extension = Utf8Path::new(import).with_extension(""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just calling out that this will convert something like types.d.ts
to types.d
source, is that the desired behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I originally had an explicit check for types.d.ts
that stripped it all the way back to types
but when I ran this on the other repo, that didn't fix any errors. I suspect oxc-resolver also treats types.d
as the name, so this should work just fine
Description
Invalid extensions are unfortunately too common in imports. Therefore if we can't resolve with the extension, we strip it and try again.
Testing Instructions
Added a test where we try to import with the wrong extension