Implicitly add 'util' to dependencies because it is used in the codebase

[Artem Zhivoderov]

Describe the bug
util npm package is referenced from the code but is not claimed to be a dependency as per package.json. This leads to inconsistent behaviour when other modules in the consumer application also depend on util. Sinon is not tied to a specific version of the module, which may resolve to other versions depending on the adjacent modules.

Why is this even a problem? Starting from v0.12.1 util contains a top level condition which accesses process.env.NODE_DEBUG which is not compatible with running in a browser. Depending on the bundler process may be polyfilled, but this is not done by default in Webpack starting from v5.

A possible solution would be to add util dependency to package.json to capture a specific version of the library (v0.12.0 doesn't produce the issue with process).

To Reproduce
Steps to reproduce the behavior:

1. Clone repo [e-mail]:azhiv/ember-sinon-msw.git
2. Run yarn + yarn test:ember -s
3. Tests are not run, the web page is empty. Check the console in the browser for the error.

Expected behavior
Tests are run successfully.

Screenshots

Context (please complete the following information):

• Library version: 15.0.1
• Environment: Chrome 108.0.5359.124
• Example URL: http://localhost:7357
• Other libraries you are using: msw

[Carl-Erik Kopseng]

Good point. Relying on Node built-ins being shimmed successfully by bundlers when building for browsers does not seem like a bullet-proof solution, as it. It looks like explicitly depending on the NPM packageutil by browserify is the right solution here. @mroderick or @mantoni?

Related to #2448.

[Maximilian Antoni]

We have util added as a dependency in referee and referee-sinon already. So it's currently implicitly installed through the @sinonjs/referee-sinon dependency here.

👍 for adding it as a dependency explicitly here too.

[Carl-Erik Kopseng]

From the webpack build log above it at least seems like implicitly depending on the util shim does not "work". Unfortunately, after testing it out (adding util and doing yarn link to sinon locally and using yarn link sinon in your repo) neither does explicitly depending on it. And according to the util docs, neither should it:

From the util package's own description:

You usually do not have to install util yourself. If your code runs in Node.js, util is built in. If your code runs in the browser, bundlers like browserify or webpack (up to version 4 -- see this documentation for how to include polyfills like util in webpack 5+) also include the util module.

Note the version 5 caveat, as I can see you are using version 5 of webpack. Just having the dependency is not enough, you also need to configure the fallback yourself. I took a pass at figuring out how Ember does this, as I could not see any webpack config in your project, but I only stumbled upon some vegetables (Broccoli), so that is up to you to figure out :)

The docs show how it would normally look (observe the process field):

So closing this as it seems to be down to user configurable bits. Shout out if I got it wrong!

[Andrey Fel]

Having a custom config in the app is fine, what we were trying to say is that sinon needs to specify the exact version of util it depends on. It would justify the need for that special configuration.
In the current situation, some random version of util is picked up. In our case, we have a yarn workspace. Adding a new dep (msw.js) to one of the apps in the workspace made it necessary to add a custom config to the other apps because before adding that new dep util was resolved to an older version (0.10), after that it picked up a new version (0.12.1) across the yarn workspace which requires a custom webpack configuration.

[Carl-Erik Kopseng]

What version of util we depend upon is a bit hard to tell, in a way, as most of the time it is whatever is built-in to Node and that is used by most installs, but I am sure we can stick the external shim package used by bundlers to some explicit version, no problem. Still won't make the issue above go away. If you could try adding the relevant config to your project I could use that as a verification step that it works fine.

I can also just do npm i util@latest ASAP and publish a new version without testing: whatever floats your boat.

[Andrey Fel]

We use ember-auto-import which is using webpack@5 under the hood to import sinon. We've added the following settings to make it work:

  autoImport: {
      webpack: {
        plugins: [
          new webpack.DefinePlugin({
            'process.env.NODE_DEBUG': 'false',
          }),
        ],
      }
  }

[Artem Zhivoderov]

I updated the initial repo with a fix, the tests are not failing now.