Copy-webpack-plugin: Import & Typescript support

[ietabhi]

When i convert to typescript, below code not working:-

import * as CopyWebpackPlugin from 'copy-webpack-plugin';

const config = {
plugins: [
new CopyWebpackPlugin([ ...patterns ], options)
]
}

[alexander-akait]

@ietabhi how it is related to plugin, looks you don't know how to right way use typescript

[ietabhi]

Getting error when compiling : Only a void function can be called with the 'new' keyword

[ericdrobinson]

I'm encountering the same issue when using a jsconfig.json file to assist in type-checking the Webpack config files as JavaScript. This results in the following error:

Only a void function can be called with the 'new' keyword.

The problem here is that the CleanWebpackPlugin is a function that explicitly returns a new object. When called, all the properties and settings are wrapped up (captured) in the apply function and _explicitly_ returned as a new anonymous object instance.

Therefore, there is no need to use the new keyword with CopyWebpackPlugin. You simply adjust your code to the following:

import * as CopyWebpackPlugin from 'copy-webpack-plugin';

const config = {
    plugins: [
        CopyWebpackPlugin([ ...patterns ], options)
    ]
}

That should clear up any errors that you see. Did for me in the pure JavaScript space. I further tested it by adding multiple calls to CopyWebpackPlugin() in the same plugins array and everything worked as expected.

If someone knows of a reason why the new keyword _would_ be necessary here, please let us know!

---

As a side note, I have the strict compilerOption enabled in my jsconfig.json file. This results in another error:

'new' expression, whose target lacks a construct signature, implicitly has 'any' type.

This issue is "resolved" in the same manner as above: remove the new keyword in use.

[alexander-akait]

Looks bug :confused: Feel free to send PR

[ericdrobinson]

@evilebottnawi This isn't a bug: it's a design choice. It's inconsistent with most Webpack plugins, of course, but it's not specifically "broken".

"Fixing" this would mean rearchitecting it such that it conformed to standard (classic) JavaScript "class" architecture. For a pretty straightforward example, check out the CleanWebpackPlugin source. In that code you'll see that:

1. The constructor object is just a function definition without a return statement.
2. The apply function is attached to the constructor object's prototype.
3. It does some specific handling of this for various contexts, likely to support various calling conventions.

Addressing this would require a larger rearchitecture of the plugin code. I would recommend that one of the maintainers drive/guide such a transition, rather than request a community PR.