Just interested - what was the reasoning behind the removal of CommonJS support in v4.0.0?

[retroburst]

Hey all,

First of all, thank you to everyone that contributes to these awesome opensource modules like emailjs!

I wanted to ask about the latest release. It seems CommonJS support was removed in v4.0.0, whereas v3.8.1 supported both CommonJS and ESModule systems. I'm wondering what was the reasoning behind the decision to remove CommonJS support considering it is (as far as I know) still the default and standard module loading system for NodeJS? Is this the way the ecosystem is heading?

I'm just interested because I maintain a large NodeJS application written in the 2016 era, so it is going to be a lot of work to convert it to use import syntax, plus there doesn't seem to be a nice / non-clunky way to use both require and import in the one file.

Thanks for your thoughts!

[zackschuster]

ideally, yes, we never would have dropped our commonjs support; nothing in our code depends on one module system or the other, after all. unfortunately, a major update to our testing library broke our ability to dynamically switch between module formats — meaning that we could only test on one module format — and it was unclear if it would be possible to restore it, given the nature of the change. at the same time, we were being forced to drop node@10 due to other issues in our dependency tree.

summarized list of notable issues

• a major update to our linter broke the ability to lint on that platform
• the commonjs testing path used an essentially unmaintained codepath in the library which handled transpiling at runtime
• that library itself had technically already dropped support for node@10, meaning it was lucky we were able to run it at all on that platform.

since node@12 is the earliest version that supports native modules without a flag, and since native modules are part of the language & therefore innately more attractive than commonjs, we decided to go with that module format as our sole target moving forward. this also greatly simplified the project structure and carried the neat tack-on effect of having a file named email.js be the literal focal point of the project named email.js.

that doesn't preclude us from restoring support if our tooling permits, but given the effort that's likely to entail i doubt it'll happen on either our end or the testing library's end any time soon. in the meantime, i'd encourage you to either stay on v3 (as the code is essentially unchanged) or compile v4 to commonjs somehow for use in your application.

[retroburst]

Thanks very much for your detailed response @zackschuster, much appreciated. Based on your reply I will stay on v3 for now, but I will move the codebase to es module / import syntax when I can, as it looks like this is where it's all going to move to.