Summary

This PR exposes importAttributes to the loader interface so loaders can react to metadata on import/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 parsed ImportAttributes from the dependency/resolve data into NormalModule and then into the loader context as _importAttributes, so loaders can read them via this._importAttributes.

High-level implementation:

• Extend NormalModuleFactory to include importAttributes in the createData passed to NormalModule.
• Store importAttributes 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 a configCases test case under test/configCases/loaders/import-attributes-loader-context:
  • A custom loader reads this._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, otherwise undefined) 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 when with { 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 otherwise undefined.