Webpack 5 'path' fallback broken when using @embroider/webpack

[ztjohns]

Configuration

Node 16.15.3
Ember 3.28.5
Webpack 5 / ember-auto-import 2+

Following webpack 5's docs explicitly to setup a fallback for 'path' when using the usual ember-cli-build return app.toTree() this poly fill works fine.

// ember-cli-build.js
autoImport: {
  webpack: {
    plugins: [
      new webpack.ProvidePlugin({process: 'process/browser'})
    ],
    resolve: {
      fallback: {
        path: require.resolve('path-browserify')
      },
      alias: {
        process: 'process/browser'
      }
    },
    node: {
      global: true
    }
  }
}

When attempting to update to use @embroider/webpack following installation instructions and replacing the former with

// return app.toTree();
const { Webpack } = require('@embroider/webpack');
return require('@embroider/compat').compatBuild(app, Webpack, {})

Error / Bug

We now get an error thrown from a dependency (i am going to shorthand this error) as:
Module not found: Error: Can't resolve 'path' in '.../node_modules/nedb/lib/persistence.js'
BREAKING CHANGE: webpack < 5 used to include polyfills ...
If you want to include a polyfill, you need to:

• add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }'
• install 'path-browserify'

Expected Behavior

For 'path' to still be resolved. I saw another thread where index.js for the package had to be directly referenced. I tried many combinations of this and it did not seem to resolve the issue.

[Windvis]

I think this is a duplicate of #699.

@embroider/webpack doesn't use ember-auto-import's Webpack config so you need to pass those options to the Embroider wepbackConfig object instead.

Untested but it would be something like this according to the readme:

return require('@embroider/compat').compatBuild(app, Webpack, {
  packagerOptions: {
    webpackConfig: {
      plugins: [
        new webpack.ProvidePlugin({process: 'process/browser'})
      ],
      resolve: {
        fallback: {
          path: require.resolve('path-browserify')
        },
        alias: {
          process: 'process/browser'
        }
      },
      node: {
        global: true
      }
    }
  }
});

[ztjohns]

@Windvis thanks, yep actually I discovered this was the case as well. Thanks for the info.