You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This topic is still up for discussion and is in issue format to perform the necessary investigation that impacts this issue.
As long as we are shipping in multiple formats (CJS & ESM) there are a few associated risks and hinderances that over time have been impacting development (1), and our confidence in what we are delivering (1, 2).
Recently we are seeing some packages migrate to shipping ESM only. Given Node v22 now has native support for ESM this could also be a good time for us to migrate. Other benefits include:
Removal of a lot of build infra
Simplified ESM only tooling and we can use ESM only dependencies
Ship the same code to consumers that we are writing (no CJS transpilation)
No more masqueraded ESM types
However, we cannot underestimate the impact this could have on consumers. As we've experienced, it's fustrating when a package upgrades and adopts ESM only and we face unnecessary pain to integrate it, or have to find another viable option.
Firstly, we should carry out an investigation on our front-end applications (explorer, wallet etc.) and the wider eco-system to understand impact. I'll add further tasks to the below list as this issue develops.
Tasks:
Investigate ESM only integration with FE applications
Investigate ESM only integration within the eco-system (via Fuel Builders).
I've tried to keep this issue pretty clean, but there are some interesting discussions around adopting ESM only here (1, 2, 3).
The text was updated successfully, but these errors were encountered:
Note
This topic is still up for discussion and is in issue format to perform the necessary investigation that impacts this issue.
As long as we are shipping in multiple formats (CJS & ESM) there are a few associated risks and hinderances that over time have been impacting development (1), and our confidence in what we are delivering (1, 2).
Recently we are seeing some packages migrate to shipping ESM only. Given Node
v22
now has native support for ESM this could also be a good time for us to migrate. Other benefits include:However, we cannot underestimate the impact this could have on consumers. As we've experienced, it's fustrating when a package upgrades and adopts ESM only and we face unnecessary pain to integrate it, or have to find another viable option.
Firstly, we should carry out an investigation on our front-end applications (explorer, wallet etc.) and the wider eco-system to understand impact. I'll add further tasks to the below list as this issue develops.
Tasks:
The text was updated successfully, but these errors were encountered: