cressie176
commented
1 year ago Hi @revosw,
Thank you for your offer of converting both Rascal and amqplib to ESM, and also for discussing your proposal in advance. My starting point is that I would be reluctant to maintain two branches of either amqplib or rascal, and also reluctant to increase minimum Node.js version for amqlib due to it's substantial user base. I'm less concerned about rascal though - is it possible to update one and not the other?
That said, I'm not very familiar with ESM yet, so it would be helpful to understand the benefits and whether there are any other implications. In my limited experience the other general considerations when converting modules are...
- A type field needs to be added to the package.json
- Modules must be imported using the full file path including the file extension
- Modules must be imported using the
importkeyword and notrequire - Dynamic imports are asynchronous (I think this might be solved in Node 20)
- The require cache is no longer a thing
I'm not aware of the benefits, particularly for backend code. I'll do a bit of reading, but it's always good to hear from someone directly too.
The npm ecosystem has gotten far in terms of ESM support. Since I use rascal at work, and rascal depends on amqplib, I would like to try to convert both to ESM to reap the benefits and move the ecosystem even further.
Although it seems managable to convert it within a weekend, I'm not sure how ditching CommonJS entirely in favor of ESM will affect the users. Do the users have blockers for adopting ESM? Is it too cumbersome for maintainers to maintain two branches - one 0.10.x for commonjs and one 0.11.x for esm? Or even both side-by-side?
Another consideration is that the minimum required Node.js version likely has to be changed from v10 to v14, as v14 is the version where ESM support was stabilized.