-
Notifications
You must be signed in to change notification settings - Fork 192
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: monomorphic ResolveRequest object #445
base: main
Are you sure you want to change the base?
Conversation
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.
Copilot reviewed 5 out of 20 changed files in this pull request and generated 1 comment.
Files not reviewed (15)
- lib/ResolverFactory.js: Evaluated as low risk
- lib/ModulesInHierarchicalDirectoriesPlugin.js: Evaluated as low risk
- lib/SymlinkPlugin.js: Evaluated as low risk
- lib/ModulesInRootPlugin.js: Evaluated as low risk
- lib/AppendPlugin.js: Evaluated as low risk
- lib/DescriptionFilePlugin.js: Evaluated as low risk
- lib/JoinRequestPartPlugin.js: Evaluated as low risk
- lib/ExportsFieldPlugin.js: Evaluated as low risk
- lib/AliasFieldPlugin.js: Evaluated as low risk
- lib/ResultPlugin.js: Evaluated as low risk
- lib/AliasPlugin.js: Evaluated as low risk
- lib/RootsPlugin.js: Evaluated as low risk
- lib/ImportsFieldPlugin.js: Evaluated as low risk
- lib/CloneBasenamePlugin.js: Evaluated as low risk
- lib/JoinRequestPlugin.js: Evaluated as low risk
Comments suppressed due to low confidence (1)
lib/ParsePlugin.js:55
- The logic for setting the 'fragment' property might not correctly handle cases where both 'parsed.fragment' and 'request.fragment' are falsy. Consider using 'parsed.fragment ?? request.fragment' to handle these cases correctly.
fragment: parsed.fragment || request.fragment || parsed.fragment,
|
||
request: parsed.request, | ||
// If parsed.query and request.query are both falsy, prefer parsed.query | ||
query: parsed.query || request.query || parsed.query, |
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.
The logic for setting the 'query' property might not correctly handle cases where both 'parsed.query' and 'request.query' are falsy. Consider using 'parsed.query ?? request.query' to handle these cases correctly.
query: parsed.query || request.query || parsed.query, | |
query: parsed.query ?? request.query, |
Copilot is powered by AI, so mistakes are possible. Review output carefully before use.
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.
This is expressly written the way it is written for the scenario where parsed.query
and request.query
are both falsy, such that it shall prefer the raw value of parsed.query
in that scenario.
Improves performance all-up (especially in
ParsePlugin
,JoinRequestPlugin
,JoinRequestPartPlugin
) by ensuring that theResolveRequest
object always has a constant shape.Note that this is technically a breaking change to plugin authors, if they took a dependency on the ability to attach arbitrary properties to the
ResolveRequest
object to pass them between plugins and out of the resolver, instead of using thecontext
property.Additionally, creating the object via a direct object literal is significantly faster than creating it via object spread.
Testing on NodeJS 18.19.1, this had the following impact for a local webpack build.
Before:
After: