fix: only import webpack types

[goloveychuk]

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

If yes, then include "BREAKING CHANGES:" in the first commit message body, followed by a description of what is breaking.

List any relevant issue numbers:

Description

So I've somehow messed with dependency tree (with monorepo+linking) and webpack loaded twise.
While you have setup webpack as peerDep and everything should be ok, I guess better to get webpack module provided instead of importing it. Also easier ts types

[goloveychuk]

reapprove please

[shellscape]

Please rebase from upstream/master

[shellscape]

The use of as any here will be a blocker for this PR

[goloveychuk]

second try. Webpack types are incorrect. Afaik object type is not assignable to other "objects"

[goloveychuk]

so without casting it won't work

[shellscape]

look at the types before your changes (what's on master), and compare to what it is with your changes, adjust from there.

[goloveychuk]

before my change it has import

// @ts-ignore
import NormalModule from 'webpack/lib/NormalModule';

so NormalModule was any.
You suggest to replicate previous types, so I'll need to

    const NormalModule = compiler.webpack.NormalModule as any;

[goloveychuk]

I think upcasting from object to more specific type inside normalmodule hook is better, more types are preserved/checked

[goloveychuk]

second try.

By this I meant that I've made second fix, removed as any.

[shellscape]

made more updates to upstream/master. webpack needed an upgrade to support node v18 in the tests.

[goloveychuk]

rebased

[goloveychuk]

I think there is no better fix, wdyt?

[wlblanchette]

Wanted to drop a comment here that this fix solves an instance of TypeError: The 'compilation' argument must be an instance of Compilation that results from a monorepo environment where the webpack configuration is defined in one package, with one instance of webpack and then imported into a second package where, for whatever reason, the second package its own instance of webpack.

In our case, it was a symptom of hoisting falling over for an unknown reason, despite the webpack versions being exactly the same. However, with a similar setup with slight differences in version, this would be reproducable.

If it's helpful to have a repro of this situation, I would be happy to spin up an issue with the repro and link it to this PR.

[shellscape]

Thanks for being patient on this one.

[mxdvl]

Will this be released on NPM as v5.0.1?

Asking as we’ve had to patch this locally to make our builds work.