However is there an assumption for the third-party-thing-test that when using ESM that the imported third party module is also ESM?

Not really. You can use td.replace for CJS and td.replaceEsm for ESM. The slightly non-obvious thing is that you use td.replace for CJS even if you import it.

PR for saying that more explicitly in the documentation I believe would be welcome.

Sincere thanks for the response. I shall conduct some tests of my own and raise a PR to the documentation.

I did try as was suggested however in the scenario that I have linked even with the suggested modifications I'm not convinced that mocking a third party CJS module from a ESM module is working. I"ll update the readme in my example. I am happy to collaborate , update docs or help in any suggested way. If I am using testdouble incorrectly it may be a good case for documentation changes.

A reproduction repository would help me help you here!

The link to the repo above has the example https://github.com/ghinks/esm-issues-with-td

Nice one!

Fix the problem by adding the line

delete require.cache[require.resolve('is-number')]

before the await import('./index.js').

Explanation: this has nothing to do with ESM. You would have gotten the same result if you'd used CJS for all your files. The problem is specific to is-number, because is-number is used by Mocha as well (to prove it, run npm ls is-number). So when you import 'mocha' at the start of the test file, it's loading is-number into the cache, and thus overriding any attempts to td.replace it. The interesting thing is that if is-number was an ESM module, this would have worked, because ESM replacement is better than CJS replacement in this regard, as detailed in the documentation:

As a result, feel free to use td.replaceEsm even after you import the module. This is different from when using td.replace where you must use td.replace first before require-ing your module. (found in https://github.com/testdouble/testdouble.js/blob/main/docs/7-replacing-dependencies.md#how-module-replacement-works-for-es-modules-using-import)

Hope that was clear enough.

Fantastic a very clear explanation and received with gratitude 🙏🏻

@ghinks Two things:

1. I believe the testdouble explanations are deficient in that area (both for CJS and ESM), and I remember falling through the same trap numerous times. Maybe one day I'll tackle it in the documentation, probably through numerous examples.

2. If we're done, could you please close the issue? ☺️

Before I close this, please allow me a day to look at what was said and try to implement it. We are all in the ESM boat together and I want to understand and present some documentation changes so others do not have quite the same pain. I'm looking at the NodeJS documentation and while in ESM mode I'll not be able to access require.cache to clear things. So the strategy presented may work for this scenario while working with CJS but while working in ES Modules I"m not sure I see a mechanism to clear loaded modules. Hope, I"m not being too much of a pain. I think we both have the correct intent of clearing a path for future users of the testdouble module.

@ghinks. If the package is an ESM package, you won't have the problem: ESM proxying in testdouble handles modules that were already loaded with panache! But I agree the documentation should be clearer on this.

Actually the example is set within package.json as type module. It is not being handled correctly and as it is an ESM module I cannot clear the cache. I will push up more examples. But I believe that this is a real issue.

@ghinks the package is-number is a CJS package. That is not dependent on the package.json of the parent package.