Summary

This PR exposesimportAttributes to the loader interface so loaders can react to metadata onimport/import() statements, as requested in#20228.

Today, the parser already understands import attributes, and they are used for things like rule matching, but loaders cannot see them. This change threads the parsedImportAttributes from the dependency/resolve data into NormalModule and then into the loader context as_importAttributes, so loaders can read them viathis._importAttributes.

High-level implementation:

• Extend NormalModuleFactory to includeimportAttributes in thecreateData passed to NormalModule.
• StoreimportAttributes on NormalModule instances.
• Expose the stored attributes on the loader context as_importAttributes, following the pattern of other internal context fields like_module,_compilation, etc.
• Update declarations/LoaderContext.d.ts to include_importAttributes?: Record<string, unknown>.
• Add aconfigCases test case undertest/configCases/loaders/import-attributes-loader-context:
  • A custom loader readsthis._importAttributes and exports it.
  • One import with attributes and one without, asserting:
    • Attributes object is passed through when present.
    • undefined is produced when no attributes are present.

What kind of change does this PR introduce?

Feature.

It adds a new capability for loaders to inspect the import attributes of the module they are processing (via_importAttributes on the loader context).

Did you add tests for your changes?

Yes.

• Added a new config test:
  • test/configCases/loaders/import-attributes-loader-context/webpack.config.js
  • test/configCases/loaders/import-attributes-loader-context/loader.js
  • test/configCases/loaders/import-attributes-loader-context/index.js
• Ran targeted Jest tests for this case:
  • node node_modules/jest/bin/jest.js test/ConfigTestCases.basictest.js --no-coverage --runInBand --testNamePattern=import-attributes-loader-context
• Also ran loader/import-attributes related config tests via--testNamePattern="loaders import-attributes" to ensure existing cases still pass.

On my Windows environment, running the full Jest suite surfaces unrelated snapshot differences (absolute paths vs<cwd>) and missing optional dependencies like@swc/core /esbuild, which appear to be environment-specific and not related to this change.

Does this PR introduce a breaking change?

No.

• The change only adds a new internal property_importAttributes on the loader context.
• Existing loaders and configurations continue to work as before.
• No existing public APIs are removed or changed.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

• Loader API docs should mention that the loader context now provides_importAttributes (an object of import attributes when present, otherwiseundefined) for modules that were imported with attributes.
• It may be worth adding:
  • A short example of a loader that branches behavior based on_importAttributes (e.g., treating assets differently whenwith { type: "image", preload: true } is used).
  • A note that this is populated only when the module is reached via an import with attributes and is otherwiseundefined.