Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeScript conflict with Webpack 5 #154

Closed
msheakoski opened this issue Oct 28, 2020 · 4 comments · Fixed by #155
Closed

TypeScript conflict with Webpack 5 #154

msheakoski opened this issue Oct 28, 2020 · 4 comments · Fixed by #155

Comments

@msheakoski
Copy link

When using a TypeScript syntax webpack.config.ts config with webpack-merge 5.2.0 and Webpack 5, the following TypeScript error is generated when trying to use merge(config, {})

TS2345: Argument of type 'Configuration' is not assignable to parameter of type 'Configuration | Configuration[]'.
  Type 'import("node_modules/webpack/types").Configuration' is not assignable to type 'import("node_modules/@types/webpack/index").Configuration'.
    Types of property 'entry' are incompatible.
      Type 'string | (() => string | EntryObject | [string, ...string[]] | Promise<EntryStatic>) | EntryObject | [string, ...string[]] | undefined' is not assignable to type 'string | string[] | Entry | EntryFunc | undefined'.
        Type '() => string | EntryObject | [string, ...string[]] | Promise<EntryStatic>' is not assignable to type 'string | string[] | Entry | EntryFunc | undefined'.
          Type '() => string | EntryObject | [string, ...string[]] | Promise<EntryStatic>' is not assignable to type 'EntryFunc'.
            Type 'string | EntryObject | [string, ...string[]] | Promise<EntryStatic>' is not assignable to type 'string | string[] | Entry | Promise<string | string[] | Entry>'.
              Type 'EntryObject' is not assignable to type 'string | string[] | Entry | Promise<string | string[] | Entry>'.
                Type 'EntryObject' is not assignable to type 'string'.

This is because webpack-merge relies on @types/webpack which is for Webpack 4. Webpack 5 now includes its own types and does not rely on the external typings.

Webpack 4's entry type looks like:

interface Configuration {
  entry?: string | string[] | Entry | EntryFunc;
}

Webpack 5's entry type looks like:

type Entry =
  | string
  | (() => string | EntryObject | [string, ...string[]] | Promise<EntryStatic>)
  | EntryObject
  | [string, ...string[]];
@bebraw
Copy link
Member

bebraw commented Oct 28, 2020 via email

@msheakoski
Copy link
Author

You might be able to do it as a minor release if you defaulted the generic to the Configuration from Webpack 4. This would still allow for overriding with the Webpack 5 Configuration.

Something like:

import { Configuration } from "webpack"; // from @types/webpack
declare function merge<T = Configuration>(firstConfiguration: T | T[], ...configurations: T[]): T;

If you decide to decouple the types like moving them to a peerDependency or removing them entirely from the package, I would consider that a major release because it would break builds (especially for those dependency updating bots) until manually adding the generic.

@msheakoski
Copy link
Author

I did a little more experimenting and think you might be able to get away with removing the dependency on @types/webpack while remaining backwards compatible. The only side effect is that it loosens up the accepted types for firstConfiguration and configurations. Anything object-like will work but scalars will trigger an error.

declare function merge<T extends object>(firstConfiguration: T | T[], ...configurations: T[]): T;

@bebraw
Copy link
Member

bebraw commented Oct 29, 2020

Yeah, I think your proposal is the way to go. It's better to loosen the type a little than to break as that still allows a minor release. I'll make sure to document the caveat when implementing. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants