v7 methods cannot be stubbed

Our unit tests that use uuid stopped working. It seems that sandbox.stub(uuid, 'v4') no longer works.

const uuid = require('uuid');
const sinon = require('sinon');

const sandbox = sinon.createSandbox();
sandbox.stub(uuid, 'v4').returns('uuid');

console.log(uuid.v4());
// prints some uuidv4 instead of 'uuid'

It seems to be related to the way defineProperty is being used. Not sure if there are other implications of replacing the defineProperty by simply setting the property, but switching this:

"use strict";

Object.defineProperty(exports, "v4", {
  enumerable: true,
  get: function () {
    return _v3.default;
  }
});

var _v3 = _interopRequireDefault(require("./v4.js"));

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

to the following works.

"use strict";

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

var _v3 = _interopRequireDefault(require("./v4.js"));

exports.v4 = _v3.default;

[ctavan]

As @broofa already explained we have migrated this library to use ESModules and per the spec ESModule exports cannot be dynamically modified, so in fact everything behaves as expected. Obviously this new behavior differs from the way things behaved with CommonJS exports with the downside of not being as easily mockable as before.

I found these discussions provided some helpful context:

• https://github.com/rollup/rollup/issues/1247#issuecomment-271616021
• https://stackoverflow.com/a/50461194

As suggested above, if you really want to continue to mock the uuid module you are left with building a wrapper or using something like https://github.com/speedskater/babel-plugin-rewire#readme.

If all you want to achieve is a static output you could also try to mock the global crypto.randomBytes() method from the node crypto library or crypto.getRandomValues() for the browser.

Or you could provide your own random number generator as described in https://github.com/uuidjs/uuid#version-4-random and done in this test.

@CareLuLu-Gabriel with respect to your specific question: Looking forward I don’t think that modules should continue to be mockable in the way they were in CommonJS times so I’m reluctant on going one step back here. I assume that ESModules will become more and more common in Node.js-land pretty soon so we’ll see these mockability issues arise for many other modules as well. I think we’ll need other solutions than just sticking with CommonJS behavior.

[azizur]

I have found this works really nice.

At the top of test file:

// your regular imports here

jest.mock('uuid', () => ({ v4: () => '00000000-0000-0000-0000-000000000000' }));

// describe('test suite here', () => {

in the actual code:

import { v4 as uuidv4 } from 'uuid';