I have followed the advice given in the error message to no avail.

I intsalled the browserify-zlib and stream-browserify packages as dev deps, and updated my next.config.js to look like this, following the advice from the error message:

require('dotenv').config();

module.exports = {
  reactStrictMode: true,
  publicRuntimeConfig: {
    SERVER_URL: process.env.PAYLOAD_PUBLIC_SERVER_URL,
  },
  images: {
    domains: ['localhost', 'elkli-and-hart'],
  },
  experimental: {
    scrollRestoration: true,
  },
  async redirects() {
    return [
      {
        source: '/checkout',
        destination: '/basket/checkout',
        permanent: true,
      },
      {
        source: '/homepage',
        destination: '/',
        permanent: true,
      },
      {
        source: '/collections/category',
        destination: '/collections',
        permanent: true,
      },
      {
        source: '/essays/category',
        destination: '/essays',
        permanent: true,
      },
      {
        source: '/journal/category',
        destination: '/journal',
        permanent: true,
      },
      {
        source: '/products/category',
        destination: '/products',
        permanent: true,
      },
      {
        source: '/email/order-confirmation',
        destination: '/',
        permanent: true,
      },
    ];
  },
  images: {
    domains: ['localhost', 'elkli-and-hart', '10.0.1.236'],
  },
  webpack(config, { isServer }) {
    config.module.rules.push({
      test: /\.svg$/i,
      issuer: /\.[jt]sx?$/,
      use: ['@svgr/webpack'],
    });
    config.infrastructureLogging = {
      level: 'error',
    };
    config.resolve.fallback = {
      util: require.resolve('util/'),
      stream: require.resolve('stream-browserify'),
      zlib: require.resolve('browserify-zlib'),
      fs: false,
    };
    return config;
  },

I've also tried:

{
  ...
  webpack(config, { isServer }) {
    config.module.rules.push({
      test: /\.svg$/i,
      issuer: /\.[jt]sx?$/,
      use: ['@svgr/webpack'],
    });
    config.infrastructureLogging = {
      level: 'error',
    };
    config.resolve.fallback = {
      util: require.resolve('util/'),
      stream: false,
      zlib: false,
    };
    return config;
  },
};

And:

{
  ...
  webpack(config, { isServer }) {
    config.module.rules.push({
      test: /\.svg$/i,
      issuer: /\.[jt]sx?$/,
      use: ['@svgr/webpack'],
    });
    config.infrastructureLogging = {
      level: 'error',
    };
    config.resolve.fallback = {
      util: require.resolve('util/'),
    };
    if (!server) {
      config.resolve.fallback = {
        stream: require.resolve('stream-browserify'),
        zlib: require.resolve('browserify-zlib'),
        fs: false,
      };
    }
    return config;
  },
};

and this:

webpack(config, { isServer }) {
    config.module.rules.push({
      test: /\.svg$/i,
      issuer: /\.[jt]sx?$/,
      use: ['@svgr/webpack'],
    });
    config.infrastructureLogging = {
      level: 'error',
    };
    config.resolve.fallback = {
      util: require.resolve('util/'),
    };
    if (!isServer) {
      config.resolve.fallback = {
        fs: false,
        stream: false,
        zlib: false,
      };
    }
    return config;
  },
};

All produce the same console error.

What has changed between 13.3 and 13.4.x (this error exists on the other 13.4.x versions also) that would cause this error to surface?

I've tried to add this to my package.json :

{
  ...
  "browser": {
    "fs": false,
    "stream": false,
    "zlib": false,
    "os": false,
    "path": false
  }
}

do you still receive this error when removing the svgr rule?

I'll try... on sec

Yes, the same error persists when I completely remove that like so:

{
  ...
  webpack(config, { isServer }) {
    config.infrastructureLogging = {
      level: 'error',
    };
    config.resolve.fallback = {
      util: require.resolve('util/'),
      fs: false,
      stream: false,
      zlib: false,
    };
    return config;
  },
};

Also tried completely removing the webpack method from the config. Same. Error.

weird, it looks like you might be trying to use a server-side module somewhere in a place that is executed in the browser

so webpack fails to bundle these native dependencies

if you are able to create a reproduction project it would be very useful

has anything fundamentally changed between 13.3 and 13.4 that might affect this? Cos as mentioned, this doesn't occur on 13.3

the file that is referrenced is this ERROR in ./node_modules/next/dist/compiled/gzip-size/index.js a nextjs file, and not from my own code, right?

I can't think about a change that might have affected this, and yeah this is from an internal file which could indicate a bug from next.js itself

but you need to make a reproduction that works with 13.4 or at least breaks with 13.4.7 so they can give it a look

otherwise there isn't much we can help with since it would be all speculation of what might be wrong

what would a reproduction example look like? essentially my whole codebase?

a minimal repository just reproducting the issue, they have minimal projects for this in the examples folder:
app dir: https://github.com/vercel/next.js/tree/canary/examples/reproduction-template-app-dir
pages dir: https://github.com/vercel/next.js/tree/canary/examples/reproduction-template

if you code is open source then you might send it but its usually not the case so its easier to reproduce just what is failing with these templates so you can narrow down the potential problem

i see - thanks. Where would you start in re-creating this?
Use my existing package.json, next.config.js and remove all the proprietary stuff?

I would do this in this order:
1. try updating your next version to the latest canary and make sure it still doesn't work (npm i next@canary or yarn)
2. create a blank page in your project and check it still doesn't work
3. check what you have in _app or _document (if using the pages dir) and start removing stuff until it starts working again
4. check the middleware
5. start removing stuff from next.config.js

basically you want to narrow down what could be the issue so you can reproduce it in the other project. you can do all these tests with the new test page so you can remove your components from the equation and it greatly reduces the amount of work

ok - thanks for the pointers, I'll try and reproduce on a clean page with no components (however this error occurs before any page even loads, but I understand the need to isolate). _app and _documents make sense to try this on tho 👍

thought i'd try and incrementally install minor versions to see where this error starts, and unfortunately it doesn't seem possible to do because regardless which version of next I install, the lock files references 13.4.7, and therefore the error occurs. My currently lock file has all next deps set at 13.3.0.

You can see in this lock diff, that despite installing 13.3.1, the version and deps are 13.4.7 🤷‍♂️

thoughts on how to install minor versions without this happening?

cc @Rafael Almeida

### Update

The ERROR in ./node_modules/next/dist/compiled/gzip-size/index.js was a red herring.

The problem was to be found within PayloadCMS's (middleware) webpack 5 config. It is odd that updating next to latest exposed this error, however adding these fallbacks to it's config supressed the errors.