V4

[chrisblossom]

This is a major version bump because the @types/webpack have been removed, and cleanOnceBeforeBuildPatterns uses the compile hook afterCompile instead of emit so plugin order should no longer matter.

Also enables async removal of files for webpack 4+.

Miscellaneous package maintenance such as package upgrades done as well.

Closes: #127, #150, #155, #163

[chrisblossom]

https://github.com/facebook/docusaurus/pull/1839: We want v2 of clean-webpack-plugin that use webpack compile hook, unlike its v3 that uses emit hook. Using upstream clean-webpack-plugin will break our SSR setup and fail our build

@endiliey does using after-compile in this PR solve the issue above?

[endiliey]

It didnt work for ours because our setup is slightly complicated. We have a client and server compilation running

[chrisblossom]

@endiliey but the compile lifecycle works for your setup? What can we do here to fix this in the library. Maybe add an option for custom lifecycle clean patterns?

[endiliey]

yes it works on our setup. I am not sure why v3 used emit hook when v2 is compile since I havent really followed this repository much except for watching releases.

I am not sure whats the best solution but anyway I think its ok if cleanwebpackplugin cant satisfy all use case. We are quite happy staying in v2 modified version for now.

[chrisblossom]

@endiliey I definitely agree this / any library doesn't need to satisfy all use cases, but this one can easily adapt to yours/others with similar issues. But that being said, do you know why after-compile won't work for you just as well as compile? FYI, currently v3 uses emit.

[endiliey]

So we have one client config and another server config. It will be run in one instance of webpack. The clean webpack is ran in the client config while the server config has something called WaitPlugin (using Make hooks) that waits for client manifest file to complete (client manifest is ran on emit)

Since server compilation is usually faster, theres a high chance the wait plugin on server already detect that client manifest has been built (from previous build) but later on the client clean webpack plugin deleted it, hence causing an error.

I think this is too specific for our use case. Technically we can just run both config sequentially but we dont want that for now.

Edit & update: it's not working for us because one of our plugin is using afterCompile hook as well to emit a file, and it got deleted with clean webpack ⭕️

[MirKml]

Any update on this? It seems that @types/wepback as dependency is problematic for Typescript 4.2+. There are many errors like

node_modules/@types/webpack/index.d.ts(1260,21): error TS2707: Generic type 'SyncWaterfallHook<T, AdditionalOptions>' requires between 1 and 2 type arguments.
node_modules/@types/webpack/index.d.ts(1261,22): error TS2707: Generic type 'SyncWaterfallHook<T, AdditionalOptions>' requires between 1 and 2 type arguments.
node_modules/@types/webpack/index.d.ts(1262,19): error TS2707: Generic type 'SyncHook<T, R, AdditionalOptions>' requires between 1 and 3 type arguments.
node_modules/@types/webpack/index.d.ts(1358,29): error TS2707: Generic type 'AsyncSeriesHook<T, AdditionalOptions>' requires between 1 and 2 type arguments.
node_modules/@types/webpack/index.d.ts(1374,25): error TS2707: Generic type 'SyncHook<T, R, AdditionalOptions>' requires between 1 and 3 type arguments.

remove @types/wepback from dependencies please