@nx/node:webpack Cannot export multiple configurations

[amri04]

Current Behavior

Assigning a custom webpack configuration file does not support the ability to use multiple configurations, as webpack allows.

Expected Behavior

Being able to define multiple configurations in my custom webpack.config.ts file to feed to webpack.

Steps to Reproduce

1. set a custom webpack config option in build target options on project.json.

  "targets": {
     "build": {
       "executor": "@nrwl/node:webpack",
       "outputs": ["{options.outputPath}"],
       "defaultConfiguration": "production",
       "options": {
        ...
         "webpackConfig": "apps/app-name/webpack.config.ts"
       },

3. define custom webpack configuration.

  // ...
  module.exports = (config: Configuration, context: any) => {
     const firstConfig= {
         // ...
         output: {
             path: 'path',
             libraryTarget: 'amd',
             //...
         },
         // ...
     }
     const secondConfig= {
         // ...
         output: {
             path: 'other/path',
             libraryTarget: 'commonjs',
             //...
         },
         // ...
     }
     return [firstConfig,secondConfig];
  }
  // ...

5. Run nx run app-name:build

Failure Logs

Invalid configuration object. Webpack has been initialized using a configuration object that does not match the API schema.
 - configuration has an unknown property '0'. These properties are valid:
   object { amd?, bail?, cache?, context?, dependencies?, devServer?, devtool?, entry?, experiments?, externals?, externalsPresets?, externalsType?, ignoreWarnings?, infrastructureLogging?, loader?, mode?, module?, name?, node?, optimization?, output?, parallelism?, performance?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, snapshot?, stats?, target?, watch?, watchOptions? }
   -> Options object as provided by the user.
   For typos: please correct them.
   For loader options: webpack >= v2.0.0 no longer allows custom properties in configuration.
     Loaders should be updated to allow passing options via loader options in module.rules.
     Until loaders are updated one can use the LoaderOptionsPlugin to pass these options to the loader:
     plugins: [
       new webpack.LoaderOptionsPlugin({
         // test: /\.xxx$/, // may apply this only for some modules
         options: {
           0: …
         }
       })
     ]

Environment

   Node : 14.18.0
   OS   : win32 x64
   npm  : 8.5.3

   nx : 13.8.6
   @nrwl/angular : 13.8.6
   @nrwl/cli : 13.8.6
   @nrwl/cypress : 13.8.6
   @nrwl/detox : undefined
   @nrwl/devkit : 13.8.6
   @nrwl/eslint-plugin-nx : 13.8.6
   @nrwl/express : undefined
   @nrwl/jest : 13.8.6
   @nrwl/js : 13.8.6
   @nrwl/linter : 13.8.6
   @nrwl/nest : 13.8.6
   @nrwl/next : undefined
   @nrwl/node : 13.8.6
   @nrwl/nx-cloud : undefined
   @nrwl/react : undefined
   @nrwl/react-native : undefined
   @nrwl/schematics : undefined
   @nrwl/storybook : 13.8.6
   @nrwl/tao : 13.8.6
   @nrwl/web : undefined
   @nrwl/workspace : 13.8.6
   typescript : 4.4.4
   rxjs : 7.5.5

Remark

The issue is very similar to the one that was resolved by @sidmonta on the web executor (#9188 , #9186)

[sidmonta]

Hi @amri04, thanks for the tip. I investigated a bit and noticed that the implementation is a bit different from the web executor

nx/packages/node/src/executors/webpack/webpack.impl.ts

Line 84 in 0331b38

const config = options.webpackConfig.reduce((currentConfig, plugin) => {

I think I can do something about it without breaking backward compatibility.

Between today and tomorrow, I should be able to work on it a bit. If you'd like to help with testing, you can try my fork: https://github.com/sidmonta/nx

Thanks

[github-actions]

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs.
If we missed this issue please reply to keep it active.
Thanks for being a part of the Nx community! 🙏

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.