feat: added fetchPriority

[alexander-akait]

due to outdated fork I recreate a new

fixes #16991
fixes #16989

Summary

🤖 Generated by Copilot at 4b6eed7

This pull request adds a new feature to webpack that allows setting the fetch priority of dynamic imports, either globally or individually. This feature can improve the loading performance of async chunks by using the fetchPriority attribute on script tags. The pull request modifies several files in the lib, schemas and test folders to implement, validate and test this feature. It also updates the cspell.json file to add a new word related to this feature.

Details

🤖 Generated by Copilot at 4b6eed7

• Add a new feature to allow setting the fetch priority for dynamic imports using the fetchPriority attribute on script tags (link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link, link)
• Add a new parser option dynamicImportFetchPriority to specify the global fetch priority for dynamic imports in lib/config/defaults.js (link)
• Add a new property fetchPriority to the ChunkGroup class to store the fetch priority option for a chunk group in lib/ChunkGroup.js (link)
• Add a new case for the fetchPriority property in the ImportMetaContextDependencyParserPlugin class to parse the import.meta object for dynamic imports in lib/dependencies/ImportMetaContextDependencyParserPlugin.js (link)
• Add a new condition to the ImportParserPlugin class to check the dynamicImportFetchPriority option and set the groupOptions.fetchPriority accordingly in lib/dependencies/ImportParserPlugin.js (link)
• Add a new condition to the ImportParserPlugin class to check the webpackFetchPriority property in the importOptions object and set the groupOptions.fetchPriority accordingly or add a warning in lib/dependencies/ImportParserPlugin.js (link)
• Add a new class ChunkFetchPriorityFunctionRuntimeModule to generate the runtime code for the getFetchPriority function that returns the fetch priority for a given chunk id in lib/prefetch/ChunkFetchPriorityFunctionRuntimeModule.js (link)
• Add a new hook to the ChunkPrefetchPreloadPlugin class to iterate over the async chunks and collect the fetch priorities and add a new ChunkFetchPriorityFunctionRuntimeModule and the getFetchPriority requirement if needed in lib/prefetch/ChunkPrefetchPreloadPlugin.js (link)
• Add a new parameter hasGetFetchPriority to the LoadScriptRuntimeModule class to determine if the loadScript function should use the fetchPriority attribute or not in lib/runtime/LoadScriptRuntimeModule.js (link)
• Add a new condition to the LoadScriptRuntimeModule class to generate the code to set the fetchPriority attribute on the script tag using the getFetchPriority function and the chunk id in lib/runtime/LoadScriptRuntimeModule.js (link)
• Add a new argument fetchPriority to the loadScript function signature and pass it to the createScript function call in lib/runtime/LoadScriptRuntimeModule.js (link)
• Add a new runtime global function getFetchPriority to return the fetch priority for a given chunk id in lib/RuntimeGlobals.js (link)
• Add a new condition to the RuntimePlugin class to check the getFetchPriority requirement and pass it as an argument to the LoadScriptRuntimeModule constructor in lib/RuntimePlugin.js (link)
• Add a new condition to the JsonpChunkLoadingRuntimeModule class to check the getFetchPriority requirement and store it in a local variable withFetchPriority in lib/web/JsonpChunkLoadingRuntimeModule.js (link)
• Add a new condition to the JsonpChunkLoadingRuntimeModule class to generate the code to declare and assign the fetchPriority variable using the getFetchPriority function and the chunk id in lib/web/JsonpChunkLoadingRuntimeModule.js (link)
• Add a new argument fetchPriority to the loadScript function call and pass it if the withFetchPriority variable is true in lib/web/JsonpChunkLoadingRuntimeModule.js (link)
• Add a new schema definition for the dynamicImportFetchPriority option to validate the webpack configuration in schemas/WebpackOptions.json (link)
• Add a new test case to test the inline webpackFetchPriority option for dynamic imports in test/cases/chunks/inline-options/index.js (link)
  • Add new files a.js, b.js and c.js to test the inline webpackFetchPriority option for dynamic imports in test/cases/chunks/inline-options/dir14/ (link, link, link)
• Swap the order of the words "IIFE" and "IIFE's" and "webpack" and "webpack's" in the cspell.json file to keep the words in alphabetical order (link, link)
• Remove the second argument of false from the call to the getChildIdsByOrdersMap method of the chunk object in the ChunkPrefetchPreloadPlugin class, which is not needed since the fetch priority is optional (link)
• Destructure the dynamicImportFetchPriority option from the options object and store it in a local variable in the ImportParserPlugin class, which is a minor refactoring (link)
• Add a new file a.js to test the global dynamicImportFetchPriority option for dynamic imports in test/configCases/web/fetch-priority-2/ (link)
  • Add new files b.js and c.js to test the global dynamicImportFetchPriority option for dynamic imports in test/configCases/web/fetch-priority-2/ (link, link)
• Add a new default value for the dynamicImportFetchPriority option to test the default values of the webpack configuration in test/Defaults.unittest.js (link)

[webpack-bot]

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

[alexander-akait]

@aboktor @Zlatkovsky please take a look, fixed:

• no boolean value anymore (except false, only for configuration, it means chunks groups don't have fetchpriorty attribute by default)
• do not override and use the first found value, for others groups it no longer matters because after loading chunk we will not load it anymore

[TheLarkInn]

@aboktor Hey would you like to review this and then inquire if there is anything that doesn't seem clear. We'll discuss and then we will land this in next weeks release.

[TheLarkInn]

Also @Zlatkovsky would you mind re-reviewing as well. Just want to make sure we are all aligned on the feature/goals/api surface and that this solves your scenario.

[aboktor]

Took a look through this. I want to validate my understanding. Here is how I understand things in their current state:

1. fetchPriority for a chunk is computed at bundle time (my initial PR was computing fetchPriority for a chunk at runtime, based on which async entrypoint requested it). I want to make sure that it is a conscious decision that we want fetchPriority to be decided at bundle time.
2. fetchPriority will be taken from the async entrypoint with the highest prefetchOrder if more than one exists.

Questions:
Is prefetchOrder computed based on the dependency graph and thus makes sense to use here to decide on fetchPriority?

Comments:
I still think that #2 above is a bit counter intuitive. One thing we could do here is to take the highest fetchPriority from all async entrypoints that require a particular chunk ( undefined < "auto" < "low" < "high" ).

LGTM otherwise :).
@alexander-akait

[Zlatkovsky]

Looks good to me. For what it's worth, I know that @aboktor tried setting fetch-priority (just via a quick patch) in an app he was working on, and did not see a statistically-significant end-to-end difference in how quickly that specific app loaded. I have an opportunity to try it out as well in a different context, but won't know if it helped or not for another few weeks.

It still seems like this should only be a good thing; but just an FYI that we don't yet have an empirical-evidence case of where setting the fetch priority helps.

[alexander-akait]

Questions:
Is prefetchOrder computed based on the dependency graph and thus makes sense to use here to decide on fetchPriority?

You can have prefetchOrder (and not have, in this case it is just 0), so it will be used only when prefetchOrder exists, to be compatibility with with prefetch

I still think that #2 above is a bit counter intuitive. One thing we could do here is to take the highest fetchPriority from all async entrypoints that require a particular chunk ( undefined < "auto" < "low" < "high" ).

Yeah, let's add tests too and give me time to think about it (today), we should not increase our runtime when developer doesn't use it, but I see what do you mean

We need to ship it for the next release 😄

[alexander-akait]

@aboktor @Zlatkovsky

I refactor again and added tests, because I agree when you if something if (value) { await import(...) } else { await import(...) } you will have magic and can't predicate what will be used, but now we generate code only when it requires, so your runtime will be the same if you don't use fetchPriority, now should be no problems (I hope 😄 )

There is intresting thing - we use import(...) for es2020 and web target, and because import(...) doesn't have the such ability, you can't use this feature, I would say it's not consistent between the specs (ES modules and HTML)

[TheLarkInn]

@chenxsan there are 2 specific ways to specify this new feature one is magic comments, and the other is a configuration setting on parser.javascript setting. The tests have both scenarios. Please feel free to ping @alexander-akait if you have any questions about the documentation.

[TheLarkInn]

@aboktor Thank you for your first contribution to webpack! 🎉

[webpack-bot]

I've created an issue to document this in webpack/webpack.js.org.

[aboktor]

@aboktor Thank you for your first contribution to webpack! tada

Thank you and @alexander-akait for the great collaboration experience!