feat(turbopack): optimize resolve plugin conditions with Option #92
Conversation
Summary of ChangesHello @xusd320, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant optimization to Turbopack's resolution plugin system. By refactoring plugin conditions to use Rust's Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the resolution plugin traits to use Option for their conditions, which is a good optimization to avoid expensive matches calls. The changes across the various plugins are consistent with this new approach.
However, I've found a potential correctness issue in how the matches task is being called in turbopack/crates/turbopack-core/src/resolve/mod.rs. The Vc is being resolved to its value before the task is called, which is not the standard pattern for turbo_tasks. I've provided suggestions to fix this.
Additionally, the logic for handling these optional conditions can be simplified to improve readability and reduce code duplication. My suggestions also include refactoring for better maintainability. Please review the detailed comments.
| let condition_option = plugin.before_resolve_condition().await?; | ||
| if let Some(condition) = *condition_option { | ||
| let condition = condition.resolve().await?; | ||
| if !*condition.matches(request).await? { | ||
| continue; | ||
| } | ||
| } |
There was a problem hiding this comment.
This block has a potential correctness issue and can be refactored for better readability.
condition.resolve().await?resolves theVcto anArc<...>, butturbo_tasks::functions likematchesshould be called on theVcitself.- The logic can be flattened to avoid nested
ifstatements by first determining if the condition matches, and then acting on it.
Here is a suggested refactoring that addresses both points.
| let condition_option = plugin.before_resolve_condition().await?; | |
| if let Some(condition) = *condition_option { | |
| let condition = condition.resolve().await?; | |
| if !*condition.matches(request).await? { | |
| continue; | |
| } | |
| } | |
| let condition_option = plugin.before_resolve_condition().await?; | |
| let matches = if let Some(condition) = *condition_option { | |
| *condition.resolve().matches(request).await? | |
| } else { | |
| true | |
| }; | |
| if !matches { | |
| continue; | |
| } |
| let after_resolve_condition_option = plugin.after_resolve_condition().await?; | ||
| if let Some(after_resolve_condition) = *after_resolve_condition_option { | ||
| let after_resolve_condition = after_resolve_condition.resolve().await?; | ||
| if *after_resolve_condition.matches(path.clone()).await? | ||
| && let Some(result) = *plugin | ||
| .after_resolve( | ||
| path.clone(), | ||
| lookup_path.clone(), | ||
| reference_type.clone(), | ||
| request, | ||
| ) | ||
| .await? | ||
| { | ||
| return Ok(Some(*result)); | ||
| } | ||
| } else if let Some(result) = *plugin | ||
| .after_resolve( | ||
| path.clone(), | ||
| lookup_path.clone(), | ||
| reference_type.clone(), | ||
| request, | ||
| ) | ||
| .await? | ||
| { | ||
| // If there is no condition, the plugin applies to all paths. | ||
| return Ok(Some(*result)); | ||
| } |
There was a problem hiding this comment.
This block has a potential correctness issue and can be significantly simplified to improve readability and reduce code duplication.
- Similar to the
before_resolvehandler,after_resolve_condition.resolve().await?is used, which is likely incorrect for calling aturbo_tasks::function.matchesshould be called on theVc. - The
plugin.after_resolve(...)call is duplicated in both theifandelse ifbranches. - The overall logic can be flattened.
Here's a suggested refactoring that addresses these points.
let after_resolve_condition_option = plugin.after_resolve_condition().await?;
let matches = if let Some(after_resolve_condition) = *after_resolve_condition_option {
*after_resolve_condition.resolve().matches(path.clone()).await?
} else {
// If there is no condition, the plugin applies to all paths.
true
};
if matches {
if let Some(result) = *plugin
.after_resolve(
path.clone(),
lookup_path.clone(),
reference_type.clone(),
request,
)
.await?
{
return Ok(Some(*result));
}
}
This PR refactors the Resolution Plugin traits to use Option for their conditions. This allow plugins to return None, skipping the expensive matches task calls entirely. Testing on a medium project showed a reduction of resolve_call tasks.