Error: Rule can only have one resource source with Webpack 5

[marekdedic]

Bug report

What is the current behavior?
Webpack 5.0 fails to build with the error: "Rule can only have one resource source".

If the current behavior is a bug, please provide the steps to reproduce.

I have create a minimal repro over at https://github.com/skaut/shared-drive-mover/tree/webpack-5-issue-repro
This issue consist of many "moving parts", removing any of them leads to it not manifesting.

My current behaviour of the repro is as follows:

$ gulp build
[18:09:32] Using gulpfile ~/shared-drive-mover/gulpfile.js
[18:09:32] Starting 'build'...
[18:09:33] 'build' errored after 349 ms
[18:09:33] Error: Rule can only have one resource source (provided resource and test + include + exclude) in {
  "exclude": {},
  "use": [
    {
      "loader": "ts-loader",
      "options": {
        "appendTsSuffixTo": [
          {}
        ]
      },
      "ident": "clonedRuleSet-1[0].rules[0]"
    }
  ]
}
    at checkResourceSource (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/RuleSet.js:167:11)
    at Function.normalizeRule (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/RuleSet.js:198:4)
    at /home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/RuleSet.js:110:20
    at Array.map (<anonymous>)
    at Function.normalizeRules (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/RuleSet.js:109:17)
    at new RuleSet (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/RuleSet.js:104:24)
    at new NormalModuleFactory (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/NormalModuleFactory.js:115:18)
    at Compiler.createNormalModuleFactory (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:636:31)
    at Compiler.newCompilationParams (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:653:30)
    at Compiler.compile (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:661:23)
    at /home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:321:11
    at Compiler.readRecords (/home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:529:11)
    at /home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:318:10
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/user/shared-drive-mover/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/home/user/shared-drive-mover/node_modules/tapable/lib/Hook.js:154:20)
    at /home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:315:19

This only happens when invoking webpack through webpack-stream, but the author of that thinks the issue lies in webpack. See shama/webpack-stream#233.

What is the expected behavior?

No crash and correct output in the dist directory - as it is with webpack@v4.

Other relevant information:
webpack version: 5.21.2
Node.js version: 14.15.5
Operating System: Debian testing
Additional tools: gulp, ts-loader, typescript, vue, vue-loader, webpack-stream

[webpack-bot]

For maintainers only:

• webpack-4
• webpack-5
• bug
• critical-bug
• enhancement
• documentation
• performance
• dependencies
• question

[marekdedic]

#12048 and #12051 may be related.

[alexander-akait]

webpack-stream still use v4 https://github.com/shama/webpack-stream/blob/master/package.json#L39, don't use multiple version of webpack and avoid duplication of issues shama/webpack-stream#233

[alexander-akait]

Problem here https://github.com/vuejs/vue-loader/blob/master/lib/plugin.js#L1, due webpack hoist you have false https://github.com/vuejs/vue-loader/blob/master/lib/plugin.js#L4 here, so plugin uses logic for v4

[alexander-akait]

webpack-stream should move webpack to peerDependencies so that the package manager does the correct installation

[alexander-akait]

You can see it here

    ...
    at AsyncSeriesHook.lazyCompileHook (/home/user/shared-drive-mover/node_modules/tapable/lib/Hook.js:154:20)
    at /home/user/shared-drive-mover/node_modules/webpack-stream/node_modules/webpack/lib/Compiler.js:315:19

you use webpack from webpack-stream, but vue-loader added plugin for v5

[shama]

I'm willing to consider moving webpack to peerDependencies if you think it would work better with the webpack ecosystem. In the past dealing with plugins, peerDependencies caused me more trouble than it solved where you had to finesse all your plugins to the right versions in order to upgrade the framework... as opposed to the library just using the version known to work independently. But if webpack plugins generally have good backwards compatibility I guess that problem is avoided.

@alexander-akait Has the webpack team considered supporting a streaming interface? Then I could just deprecate webpack-stream.

[alexander-akait]

I'm willing to consider moving webpack to peerDependencies if you think it would work better with the webpack ecosystem. In the past dealing with plugins, peerDependencies caused me more trouble than it solved where you had to finesse all your plugins to the right versions in order to upgrade the framework... as opposed to the library just using the version known to work independently. But if webpack plugins generally have good backwards compatibility I guess that problem is avoided.

All loaders and plugins have webpack in peerDependencies. It is best practice, otherwise you will get these problem.

@alexander-akait Has the webpack team considered supporting a streaming interface? Then I could just deprecate webpack-stream.

No we don't have streaming interface, nobody request this, maybe because they found webpack-stream...