CJS → ESM #341

Activity

1. JakobJingleheimer

   added this to the CJS → ESM milestone on Jan 22, 2026
2. JakobJingleheimer

   assigned

   AugustinMauroy

   on Jan 22, 2026
3. JakobJingleheimer

   added this to Userland Migrations Boardon Jan 22, 2026
4. JakobJingleheimer

   added sub-issues on Jan 22, 2026

   • CJS → ESM: wrapper - package.json updates #342
   • CJS → ESM: wrapper - update file extensions #343
   • CJS → ESM: wrapper - run API migrations #344
   • CJS → ESM: API migration - TL require → static imports #345
   • CJS → ESM: API migration - dynamic require → createRequire, import(), or import.sync() #346
   • CJS → ESM: API migration - module.exports → export #347
   • CJS → ESM: API migration - context-local variables → import.meta.* #348
5. AugustinMauroy

   moved this to 📋 Backlog in Userland Migrations Boardon Jan 22, 2026
6. AugustinMauroy commented on Jan 22, 2026

   

   AugustinMauroy

   on Jan 22, 2026

   Member

   More actions

   Update files using CJS-specific extension (.cjs → .mjs, .cts → .mts, .d.cts → .d.mts).

   IMO we shouldn't touch to typescript file for the first iteration.

   FYI: i have opened a pr as draft to make some research about the good way to handle that #340

   Also If we change the extension we will need to update some other part of the codebase which mean we need a way to track/store that.

   In term of technical part we:

   • want to have step by step thing not one jssg workflow
   • doesn't want to have one big pr with +50K

   🚨IMPORTANT 🚨
   I'm going to have a call today with codemod.com team to discuss about technical part. And with theses information I'm going to make an action plan.

   👍React with 👍2Reacted by Jacob Smith and Bruno Rodrigues
7. JakobJingleheimer commented on Jan 22, 2026

   

   JakobJingleheimer

   on Jan 22, 2026

   Last edited by JakobJingleheimer

   MemberAuthor

   More actions

   Also If we change the extension we will need to update some other part of the codebase which mean we need a way to track/store that.

   I accounted for that in the relevant sub-tickets 🙂 correct-ts-specifiers can handle that (just run it after the file extensions are changed—it should work for vanilla js extensions too; if it doesn't, it probably easily could).

   I just realised correct-ts-specifiers needs an update to also handle node:test's mock.module.

   👀React with 👀1Reacted by Augustin Mauroy
8. AugustinMauroy commented on Jan 22, 2026

   

   AugustinMauroy

   on Jan 22, 2026

   Last edited by AugustinMauroy

   Member

   More actions

   Okay what we will do :

   1. having a pr that scaffold the codemod
   2. having mutilple pr that setup the tests suite without running it. (yeah test driving development here)
   3. Adding one codemod by pr + running there test
   4. publish the codemod

   Technical constraint, if we modify file ext we will need to store data (from/to) somewhere. It's will be stored in state which is not available on steps that are Codemod Registry Step we will only use jssg step. So what it's implied for the user it's mean the user will just be able to run @nodejs/cjs-to-esm and not each step as independent thing.
   We can still block the user with manual step

   👍React with 👍1Reacted by Jacob Smith
9. JakobJingleheimer commented on Jan 22, 2026

   

   JakobJingleheimer

   on Jan 22, 2026

   MemberAuthor

   More actions

   it's mean the user will just be able to run @nodejs/cjs-to-esm and not each step as independent thing

   I think that's not necessarily true: they can run the individual steps, but they can't automatically update file extensions (which they may not even need to do). No?
10. AugustinMauroy commented on Jan 23, 2026

    

    AugustinMauroy

    on Jan 23, 2026

    Member

    More actions

    it's mean the user will just be able to run @nodejs/cjs-to-esm and not each step as independent thing

    I think that's not necessarily true: they can run the individual steps, but they can't automatically update file extensions (which they may not even need to do). No?

    Saddly if we want to harmonize everything on use codebase we need to update ext to js + update package.json type key. To not have to do some intensive fs call to verify all import specifier we can just store a from/to array. But that imply to be different JSSG step in the same codemod
11. JakobJingleheimer commented on Jan 23, 2026

    

    JakobJingleheimer

    on Jan 23, 2026

    MemberAuthor

    More actions

    No, what I mean is something like this:

    ./src
    ├  foo/
    ┆  └  …
    ├  bar/
    ┆  └  …
    ├  qux/
    ┆  └  …
    ├  zed/
    ┆  └  …
    ├  index.js
    ├  util.js
    └  …
    

    Let's say this project is a very simple case: everything is CJS and the only CJS parts are top-level require()s and straightforward module.exportss.

    No file extension updates are needed; the only "outside" update needed is setting pjson.type to "module", which doesn't depend on file extension updates.