Uncaught ReferenceError: process is not defined, won't build in Webpack #55

Cobertos · 2021-12-17T08:19:10Z

I tried building this in my project with latest webpack and got the following error:

Uncaught ReferenceError: process is not defined,

Seems like webpack is hitting a require('util/') and bundling Node.js's implementation of util, which has Node.js only code, hence the error above.

I stripped it down to a simple test case.

webpack.config.js

const path = require('path');

module.exports = {
  mode : "development",
  entry : { main: "./entry.js" },
  output : {
    path : path.resolve(__dirname, "dist"),
    filename : "[name].js",
    library : "datadesk",
    libraryTarget : "umd"
  },
  resolve: {
    fallback: {
      assert: require.resolve("assert"),
    }
  },
  devtool: "source-map"
};

entry.js

const a = require('assert');

package.json

{
  "name": "testtt",
  "version": "1.0.0",
  "dependencies": {
    "assert": "^2.0.0",
    "webpack": "^5.65.0"
  },
  "devDependencies": {
    "webpack-cli": "^4.9.1"
  }
}

testtt.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <script src="./dist/main.js"></script>
  </head>
  <body>
  </body>
</html>

Also here's the built files. You can copy and run something like python -m http.server to open, or another small http file server.

testtt.zip

I think this can be worked around by also polyfilling util in the webpack config, but there is no util-browserify package that I've found yet on npm

The text was updated successfully, but these errors were encountered:

ljharb · 2021-12-17T08:21:57Z

This is caused by webpack 5 being broken, and not polyfilling node globals by default. You’ll have to fix it by adding stuff to your config; see https://blog.sindresorhus.com/webpack-5-headache-b6ac24973bf1

Cobertos · 2021-12-17T08:53:56Z

I see.

A fix seems to be using ProvidePlugin to polyfill the global process again, as described in browserify/node-util#57

Relevant snippet

// ...
plugins: [
    new webpack.ProvidePlugin({
      // Make a global `process` variable that points to the `process` package,
      // because the `util` package expects there to be a global variable named `process`.
           // Thanks to https://stackoverflow.com/a/65018686/14239942
      process: 'process/browser'
   })
  ],
// ...

lildeadprince · 2022-07-16T19:11:27Z

I just stumbled upon the same issue, while using other 3rd-party browser targeted library, that depends on assert.
Same way as OP I've got hit by ReferenceError: process is not defined.

I'm not using webpack, though. I have Vite.js for my bundling shenanigans nowadays. But that should be completely irrelevant for the matter.

Reading the responses in this thread confused me even further.

In the first line of its description assert states that is a library for the browser. For me that means that I should not care about anything, while using it in browser. It may be assumed otherwise by the writer, but I've just got this issue from other client-library -- then guess I'm not the only one who expected it?
@ljharb is referring to a build tool behavior, that at some point of the time were enabling Node.js-targeted code to run in browser by default

For me "at some version some tool were somehow affecting user codebase by default" do not translate into nor justify the statement of "assert is browser-ready". It's just not true right now.
And a library should not justify my choice of build tools or their version.

If library requires some Node.js polyfills to run in browser -- it is not browser-ready. It's just Node.js library.
Furthermore, if library depends on some non-browser-ready Node.js library -- it (transitively) is not browser-ready as well.

Summarizing it, I suppose that we have to either:

remove the "for the browser" phrase from the library description to avoid confusions (or reword somehow, I don't know... something "for the browser (when using Webpack 4 only)" like.
properly replace Node internals and Node.js dependencies (like util), so library would actually work properly in browser with zero-config required from userland. Distribution code of a browser-targeted library may never contain stuff like "process.***", etc.

"User must update config" is not "browser-ready". One of those statements must go, I believe.

ljharb · 2022-07-16T19:56:38Z

@lildeadprince it means that you shouldn’t are while using a working node module bundler, the definition of which requires the decade-long behavior of polyfilling node builtins and globals automatically.

In other words, you shouldnt have to care about it, but some bundlers have chosen to intentionally break themselves and force you to care about it. You can either fix those bundlers via config, use a non-broken bundler, or jump through innumerable hoops trying to work around the way the ecosystem has always worked.

This package is browser-ready. The problem is that your bundler isn’t.

lildeadprince · 2022-07-16T20:33:49Z

Thank you for explaining your opinion. Not that I agree with it, but I accept it as a final statement on this topic. And also thank you for a quick reply.
I will figure solution for it on my side.

Node.js don't even need bundling. Bundlers naturally are browser only tool, so "non-brower-ready bundler" (Vite itself even) sounds like nonsense to me. And I don't think attempts of injections of some usually totally unrelated code (until none of Node internals are not in ES or browser API spec) is their job by default. I don't know why is it expected from bundler to "fix" code full of process.env, .std*, .nextTick, etc. Looks like a separate feature, not as a solid "must". Well, maybe I'm wrong. Will try exploring more opinions on later.

Ultimately I'm glad that TIL, that there is another solid opinion around and I have to and will be aware of that in future. Thanks.

BendingBender · 2023-08-22T15:58:22Z

Just my 2 cents: because this package targets browsers and a lot of users happen to use "a bundler that isn't browser-ready", it would actually be great if this incompatibility would be mentioned in the readme with a link to this thread. Would you be interested in a PR in this matter?

ljharb · 2023-08-22T16:08:12Z

Sure, if it lists a few bundlers that are broken by default (like webpack 5), and a few that work by default (like webpack < 5), that seems reasonable.

Cobertos closed this as completed Dec 17, 2021

davidnewcomb mentioned this issue Mar 10, 2022

"Process is not defined" after webpack was upgraded from version 4 to 5 VLZH/react-lightgallery#27

Open

BendingBender mentioned this issue Aug 23, 2023

Add description for usage with webpack and vite #60

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uncaught ReferenceError: process is not defined, won't build in Webpack #55

Uncaught ReferenceError: process is not defined, won't build in Webpack #55

Cobertos commented Dec 17, 2021 •

edited

Loading

ljharb commented Dec 17, 2021

Cobertos commented Dec 17, 2021 •

edited

Loading

lildeadprince commented Jul 16, 2022

ljharb commented Jul 16, 2022

lildeadprince commented Jul 16, 2022

BendingBender commented Aug 22, 2023

ljharb commented Aug 22, 2023

Uncaught ReferenceError: process is not defined, won't build in Webpack #55

Uncaught ReferenceError: process is not defined, won't build in Webpack #55

Comments

Cobertos commented Dec 17, 2021 • edited Loading

ljharb commented Dec 17, 2021

Cobertos commented Dec 17, 2021 • edited Loading

lildeadprince commented Jul 16, 2022

ljharb commented Jul 16, 2022

lildeadprince commented Jul 16, 2022

BendingBender commented Aug 22, 2023

ljharb commented Aug 22, 2023

Cobertos commented Dec 17, 2021 •

edited

Loading

Cobertos commented Dec 17, 2021 •

edited

Loading