Rewrite modules readme

[GeoffreyBooth]

I just listened to https://syntax.fm/show/211/hasty-treat-modules-in-node and the speakers there seemed to think that named exports for CommonJS were coming soon. They got this idea from the readme in this repo, because it still lists every feature we ever considered implementing, including “Named exports when importing CJS (#81)”. When that was written, the purpose of the README was to be a document setting down our agreed-upon consensus.

Now that ESM in Node has shipped, we don’t really need our consensus spelled out anymore. I think people coming to this repo today are likely to be looking for information about what’s on the roadmap for future improvements to ES modules in Node. I think the readme should answer that question directly, both in terms of what we’re working on or would be open to contributions for solving; and what isn’t likely to come to Node, with reasons why. This could also be how we retire the roadmap, moving its purpose into the readme (but the readme doesn’t need to include details about past phases; we could keep all that in some separate document).

Thoughts? Anyone like to collaborate on this?

[weswigham]

I would hope that spurs us to reinvest in making that actually happen, once the core's shipped? Most of the reason that hasn't really advanced is procedural, IMO (and we've been doing more productive things in the meantime). We do still have philosophical buyin form the tc39 to make named exports happen AFAIK, it's just going to be a long process to work through it with the committee.

[bmeck]

@weswigham to my knowledge TC39 wanted a different approach from the Dynamic Modules proposal which would affect existing module graphs so idk where/what we could invest in currently. I'm listed as the champion but was pondering closing that proposal as I don't see a path forward for that one at least.

[GeoffreyBooth]

We could also just explain the situation in more detail. It doesn't have to be go/no go, we could say we want to do it but can't find a way currently, and here's why.

[weswigham]

@bmeck IIRC you were essentially told that they didn't wanna deal with it in the SourceTextModuleRecord spec and that they should look into removing SourceTextModuleRecord from the main spec, which essentially shut you down, since that's not what you were looking for. The way forward, IMO, is to make that happen and bring that forward, as they proposed. (Where it probably gets shut down by other people and we can return to productively discussing how to actually integrate it into the spec). It's roundabout and disheartening, but probably the process that needs to happen, from what I understand.

[bmeck]

@weswigham I'd gladly cede the proposal over to you, as I do not share the confidence of it moving forward due to it affecting SourceTextModuleRecord being a requirement to my knowledge unless node ships only DynamicModuleRecords and doesn't use SourceTextModuleRecord. Let me know if you want to do such as I'm not going to queue it on the agenda anytime.

[DerekNonGeneric]

@GeoffreyBooth, I'd be interested in collaborating on the README. It might be a good idea to share any particularly good resources on best practices to help guide this effort.

• https://opensource.guide/building-community/#treat-your-readme-as-a-constitution
• https://guides.github.com/features/wikis/#Formatting-a-readme
• https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-readmes