fix: add Plugin to built-in d.ts from @types/webpack#11698
fix: add Plugin to built-in d.ts from @types/webpack#11698pastak wants to merge 1 commit intowebpack:mainfrom
Conversation
|
For maintainers only:
|
|
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
| /** @typedef {import("../declarations/WebpackOptions").WebpackOptionsNormalized} WebpackOptionsNormalized */ | ||
| /** @typedef {import("../declarations/WebpackOptions").WebpackPluginFunction} WebpackPluginFunction */ | ||
| /** @typedef {import("../declarations/WebpackOptions").WebpackPluginInstance} WebpackPluginInstance */ | ||
| /** @typedef {import("../declarations/WebpackOptions").WebpackPluginInstance} Plugin */ |
There was a problem hiding this comment.
WebpackPluginInstance and Plugin are not the same.
WebpackPluginInstance is an interface, Plugin in @types/webpack is an abstract class.
One can't use an interface with class extends WebpackPluginInstance.
You can create a new Plugin type as abstract class to create compatibility.
There was a problem hiding this comment.
Hi sokra and pastak,
I also encountered this problem. Are you going to fix it soon?
There was a problem hiding this comment.
Hi, I am still facing this issue -- any way there is going to be a fix?
|
Thanks for your contribution. I am closing PR because it is too stale.. |
6 participants
ref: #11630
Many typings of packages use
Pluginnow. If they have to change it to useWebpackPluginInstancethey treat it as a breaking change. This is a large impact on packages even if webpack@5 is a major update version and a breaking change (ex: getsentry/sentry-webpack-plugin#233 ) . Could you avoid this situation?What kind of change does this PR introduce?
bugfix
Did you add tests for your changes?
Does this PR introduce a breaking change?
no
What needs to be documented once your changes are merged?