feat: monomorphic ResolveRequest object

[dmichon-msft]

Improves performance all-up (especially in ParsePlugin, JoinRequestPlugin, JoinRequestPartPlugin) by ensuring that the ResolveRequest 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 the context 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:

[Copilot]

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,

[alexander-akait]

@dmichon-msft Yeah, I am afraid it is a breaking change...

In webpack we have such things - https://github.com/webpack/webpack/blob/main/lib/cache/ResolverCachePlugin.js#L147 and https://github.com/webpack/webpack/blob/main/lib/cache/ResolverCachePlugin.js#L150

Technically we can solve this and add a special place to store such things.

I have only remembered one place where we use it, maybe somewhere else, but it is quite possible that this is the only place

So let's try to solve it step by step

1. Implement special place to store custom values for authors (maybe just Map?)
2. Make internal helper for request generation and implement an option to back compat
3. Rewrite it in webpack and test it

Alternative solution, maybe even better, but need to check perf

1. Check request in factory (we can use Symbol isPure) - if no unknown properties it is pure (we known them), otherwise false
2. Make internal helper for creating request - if it isPure request we can use your logic and get perf improvement, if no just use olg logic
3. (Optional) And also provide a place to store custom values for authors, because to bring such improvements to webpack

So we will keep old behaviour and have perf improvement for some places

[dmichon-msft]

@dmichon-msft Yeah, I am afraid it is a breaking change...

In webpack we have such things - https://github.com/webpack/webpack/blob/main/lib/cache/ResolverCachePlugin.js#L147 and https://github.com/webpack/webpack/blob/main/lib/cache/ResolverCachePlugin.js#L150

Technically we can solve this and add a special place to store such things.

I have only remembered one place where we use it, maybe somewhere else, but it is quite possible that this is the only place

So let's try to solve it step by step

1. Implement special place to store custom values for authors (maybe just Map?)
2. Make internal helper for request generation and implement an option to back compat
3. Rewrite it in webpack and test it

Alternative solution, maybe even better, but need to check perf

1. Check request in factory (we can use Symbol isPure) - if no unknown properties it is pure (we known them), otherwise false
2. Make internal helper for creating request - if it isPure request we can use your logic and get perf improvement, if no just use olg logic
3. (Optional) And also provide a place to store custom values for authors, because to bring such improvements to webpack

So we will keep old behaviour and have perf improvement for some places

The context property is already a completely opaque object that is forwarded through the request chain without being inspected or modified in any way, so we ought to be able to just use that for the ResolverCachePlugin scenario.

[dmichon-msft]

I have some thoughts on ways to make this behavior be a resolver option, will refactor.