transformed CJS compatibility with jest

[magic-akari]

There are some issues about compatibility between common_js pass and jest.

There are some cases.

1. ESM environment with ESM test files. tracked by Meta: Native support for ES Modules jestjs/jest#9430
2. CJS environment with CJS test files. everything works well.
3. CJS environment with ESM test files or the opposite. Node-based interop. Does anyone do this kind of thing?
4. CJS environment with CJS test files which are transformed from ESM. This is what we are talking about.

The correct way is to turn case 4 into case 1 or case 2.
Because we follow ESM behaviour, exports are immutable. But we can't stop users from doing the wrong thing.
Users may want ESM output, but because of the current situation of case 1, They need jest in CJS environment.

So, can we provide a hack?
It's something like pnpm's shamefully-hoist
It's wrong, but it can help users get out of trouble and makes it Just works.

We can add a mutableExports to CJS config.
I think its role is similar to allowTopLevelThis from babel, since top level this in ESM should always be converted to undefined.
I tested locally, and simply adding a configurable: true can get jest working again (Although it shouldn't).

Related issues.

• Meta: Native support for ES Modules jestjs/jest#9430
• Cannot redefine property error when using jest.spyOn after v1.2.206 #5059
• jest.spyOn does not work when compared ts-jest #3843

[kdy1]

Hmm... I think it's acceptable, considering the amount of requests

[kwonoj]

I don't have strong opinions of the change itself, just curious if this could be done in our jest plugin and let plugin owns config option. Having this option in top level swcrc sounds somewhat awkward and opens up potential abuse.

[kwonoj]

if plugin owns this, plugin itself internally may run this core transform first with necessary handlings for the new option. (Similar to #4826).

Should we do is a separate question.

[kdy1]

I think it's better to postpone this for now

[Smrtnyk]

in swc/jest we could extend jest config with a new flag and if that new flag is set, we could add configurable: true in the transformed code if that would be all that is necessary?
that way it is separated from swc config.
I could try to work on it if there is interest and that is what is wanted?

[kdy1]

But the problem is that it's fixing broken code.

[Smrtnyk]

Yeah but we could set it at least behind a flag in jest config, so that users are not blocked to upgrade the swc, or at least until jest is more mature in regards of esm.
I get what you say, but this was a breaking change in swc (although a correct one and I agree with you) and should have at least been announced a bit better or docs updated to mention it that it will happen in 206.
We have thousands of unit tests using swc and jest and now this pretty much locked us to version 205.

[Smrtnyk]

I think this will force many of swc users that use it as jest transformer to stay locked on 205 version, at least until jest supports esm properly

[magic-akari]

I published a swc plugin.
https://www.npmjs.com/package/swc_mut_cjs_exports

This plugin will transform local exports with configurable: true, and rewrite all local export ref name with exports. (fix #3843)

usage:

{
  "$schema": "http://json.schemastore.org/swcrc",
  "jsc": {
    "experimental": {
      "plugins": [["swc_mut_cjs_exports", {}]]
    }
  },
  "module": {
    "type": "commonjs"
  }
}

Make sure that module.type is commonjs since this plugin does not touch non-workaround parts, such as import statements.

Transform example:

export const child = () => {
    console.log("Hello World!");
};

export const callChild = () => {
    child();
};

export {};
function _export(target, all) {
    for(var name in all)Object.defineProperty(target, name, {
        enumerable: true,
        get: all[name],
        configurable: true
    });
}
_export(exports, {
    child: ()=>child,
    callChild: ()=>callChild
});
const child = ()=>{
    console.log("Hello World!");
};
const callChild = ()=>{
    (0, exports.child)();
};

This plugin is only for jest workaround. Not recommended for other uses.

[kwonoj]

We have a pinned issue already, but I pinned this as well to make #5151 (comment) more visible.

[edumaciel10]

Can you give a status for this?
An official solution?

[kwonoj]

#5151 (comment) is official solution. @swc/core will not provide changes out of the box, but any userland implementation should amend as needed, either fix test codes or use 3rd party plugins.