Skip to content

Conversation

fi3ework
Copy link
Contributor

This reverts commit c951c98.

What kind of change does this PR introduce?

After discussing with @ahabhgk, we decided to correct the behavior introduced in #18660 that implicitly derive "module-import" from externalsPreset. The original implementation was a compromise and had the following drawbacks:

  1. It coupled with externalsPreset, making the options less orthogonal. externalsPreset does not fully align with the fallback intention.
  2. It complicated the internal calculation of the external type.

The revised implementation includes:

  1. Reverting commit fix: module-import get fallback from externalsPresets #18660.
  2. When a non-import or import() dependency appears, it will simply fall back to the module type (or it can also fall back to the import type).

To alter the external fallback, user can refine the handling by adding a test case like the one in this PR. User can customize the fallback type using dependencyType, for example:

externals: [
	function (
		{ context, request, contextInfo, getResolve, dependencyType },
		callback
	) {
		// Customize fallback type with dependencyType
		callback();
	},
	{
		external0: "external0",
		external1: "external1",
		external3: "external3",
		fs: "commonjs fs",
		path: "commonjs path"
	}
]

Did you add tests for your changes?

Yes.

Does this PR introduce a breaking change?

No.

What needs to be documented once your changes are merged?

Yes, I'll update if this PR got merged.

@webpack-bot
Copy link
Contributor

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants