2

I'm writing a CloudFlare worker and I have the following webpack.config.js:

'use strict';

module.exports = {
  devtool: 'source-map',
  entry: './src/main.ts',
  module: {
    rules: [
      {
        test: /\.html$/,
        loader: 'html-loader',
        options: {
          sources: false,
        },
      },
      {
        test: /\.(ico|jpg|png)$/,
        loader: 'url-loader',
      },
      {
        test: /\.txt$/,
        loader: 'raw-loader',
      },
      {
        test: /\.ts$/,
        loader: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: ['.ts', '.js'],
  },
  stats: 'errors-warnings',
  target: 'webworker',
};

For some dependencies, like the npm cookie and lodash packages this works fine. However, when I try to import eta (https://eta.js.org/), webpack imports the cjs version instead of the browser version and I get the following errors:

ERROR in ./node_modules/eta/dist/eta.cjs 5:9-22
Module not found: Error: Can't resolve 'fs' in '/home/avery/dev/28pac/worker/node_modules/eta/dist'

ERROR in ./node_modules/eta/dist/eta.cjs 6:11-26
Module not found: Error: Can't resolve 'path' in '/home/avery/dev/28pac/worker/node_modules/eta/dist'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
    - add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }'
    - install 'path-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
    resolve.fallback: { "path": false }

webpack compiled with 2 errors

Why is this happening and how do I fix it?

As far as I can tell, the eta package is written correctly and I should be getting the browser version.

btmorex
  • 356
  • 3
  • 13
  • This is indee odd. According to the `resolve.mainFields` documentation, `browser` is the preferred field for the `webworker` target. What happens if you set `resolve.mainFields: ['browser', 'main']` manually? - https://v4.webpack.js.org/configuration/resolve/#resolvemainfields – Domi May 25 '21 at 09:11
  • Also, there is another possibility, that is some other dependency is bringing in `eta` and screwing things up there. Can you check the online "webpack analyze" tool (see https://medium.com/@joeclever/three-simple-ways-to-inspect-a-webpack-bundle-7f6a8fe7195d#90e2 for explanation) to visualize the dependency graph and find out who is requiring `eta`? – Domi May 25 '21 at 09:17
  • I tried resolve.mainFields and it made no difference. eta won't be installed unless I list it under package.json – btmorex May 25 '21 at 15:16
  • Just because it won't be installed if you don't add it to `package.json`, does not mean that it is not `require`'d by any other package (and in a way that is different from your intended use). – Domi May 25 '21 at 18:24
  • What I usually do in these types of cases is: I add a custom `function` to `externals`. This allows you to analyze the context, the stack trace and even the triggering `require` call. It also allows you to possibly forcefully override how it is to be resolved, (e.g. by forcing the path of the correct file in `dist`). I feel a strong tingle that this is caused by some third party library in a way that you did not at all foresee (happened to me one too many times) - See: https://webpack.js.org/configuration/externals/#function – Domi May 25 '21 at 18:26

0 Answers0