test: extract cjs require tests to .spec.cts

[Shinigami92]

I just go a great idea over night! 💡
What if we just move all require(*)-cjs calls into .spec.cts files. That way we can more safely use the require-nodejs keyword and ensure that it really works.
But not only this, when we will remove cjs support in v10, we could ensure this way at least for newer versions of nodejs, that it still works with their new require(esm) https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	e1ad736
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/67fba6742350360008fa623a
😎 Deploy Preview	https://deploy-preview-3436.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.97%. Comparing base (81c9fba) to head (e1ad736).

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #3436      +/-   ##
==========================================
- Coverage   99.97%   99.97%   -0.01%     
==========================================
  Files        2836     2836              
  Lines      218600   218600              
  Branches      952      952              
==========================================
- Hits       218547   218545       -2     
- Misses         53       55       +2     

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xDivisionByZerox]

What if we just move all require(*)-cjs calls into .spec.cts files. That way we can more safely use the require-nodejs keyword and ensure that it really works.

What do you mean by "ensure that it really works"? Why does it not work right now? 🤔

But not only this, when we will remove cjs support in v10, we could ensure this way at least for newer versions of nodejs, that it still works with their new require(esm) nodejs.org/api/modules.html#loading-ecmascript-modules-using-require

I don't see how moving the test in a separate file ensures this behavior. As far as I can tell this would require our code base to use explicit *.m(t|j)s file extensions, which is not the case right now. Am I missing something? Could you elaborate on this?

[xDivisionByZerox]

Can you use our internal keys function (from 'src/internal/keys.ts')? That way we don't need to disable the line from linting.

[Shinigami92]

I'll try 👀

Oh, I think I did it that way, because it does not use imports from src at all, but is more an integration/e2e-test depending on the build output
That way, the test also fully ensures that nothing gets "optimized" but reads the final bundled sourcecode

[Shinigami92]

What if we just move all require(*)-cjs calls into .spec.cts files. That way we can more safely use the require-nodejs keyword and ensure that it really works.

What do you mean by "ensure that it really works"? Why does it not work right now? 🤔

Before this PR, we used require in a normal ts file which gets processed by vitest/vite and therefore potentially gets optimized (not sure if this really happens!)
When we now use .cts instead, we ensure that the file is running in pure common-js context.
https://github.com/faker-js/faker/pull/3436/files#diff-f8cd4ea46aecbba86ee9cba1a851bca523aca5e63bf9fa1866e3604a9d2dec26L9

faker/test/locale-imports.spec.ts

Line 9 in 1e551c5

const { faker } = require(`../dist/locale/${locale}.cjs`) as {

But not only this, when we will remove cjs support in v10, we could ensure this way at least for newer versions of nodejs, that it still works with their new require(esm) nodejs.org/api/modules.html#loading-ecmascript-modules-using-require

I don't see how moving the test in a separate file ensures this behavior. As far as I can tell this would require our code base to use explicit *.m(t|j)s file extensions, which is not the case right now. Am I missing something? Could you elaborate on this?

No, we wont need to ship .mjs files, because everything is controlled be package.json's "type": "module" and therefore the hole package will get consumed as pure esm package.
In combination with NodeJS's new require(esm), this finally get solved. And our .spec.cts file can cover that.

[Shinigami92]

@xDivisionByZerox in the future (v10) we might need to run this .spec.cts test with Node v20.17+ and the --experimental-require-module or Node v23+
(see https://nodejs.org/api/modules.html#loading-ecmascript-modules-using-require and open the History)

And then we need to switch the required calls to depend on v10's esm bundled code

- require('../dist/index.cjs')
+ require('../dist/index.js')

- require(`../dist/locale/${locale}.cjs`)
+ require(`../dist/locale/${locale}.js`)