Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Export the SDK as ESM Only #3447

Open
2 tasks
danielbate opened this issue Dec 5, 2024 · 8 comments
Open
2 tasks

Export the SDK as ESM Only #3447

danielbate opened this issue Dec 5, 2024 · 8 comments
Labels
chore Issue is a chore

Comments

@danielbate
Copy link
Member

danielbate commented Dec 5, 2024 •
edited
Loading

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:

  • 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).
@danielbate danielbate added the chore Issue is a chore label Dec 5, 2024
@danielbate danielbate self-assigned this Dec 5, 2024
@danielbate
Copy link
Member Author

I believe this is something we should adopt at some point, however the timing at the moment might not be right, let's see.

@petertonysmith94
Copy link
Contributor

graphql-request has transitioned over to ESM only as of v7 (6.1.0, 7.1.2, docs) and therefore is blocking upgrading.

This has significance as it's been a source of the punycode deprecation notices for node@v22+ users.

@petertonysmith94 petertonysmith94 mentioned this issue Jan 3, 2025
Merged
4 tasks
@arboleya
Copy link
Member

arboleya commented Jan 3, 2025

@petertonysmith94 What are the pros and cons? I'm concerned about how this will affect our users. Maybe we could try a PoC with the FE guys (cc @LuizAsFight) as our first consumers and see if/what obstacles arise.

@petertonysmith94
Copy link
Contributor

Pros

  • Enabling the upgrade of dependencies that have migrate to ESM only
  • Tree shaking works more reliably with ESM, which could leading to smaller bundle sizes for end users.
  • Reducing complexity of maintaining both CJS and ESM builds

Cons

  • Breaking change for users who rely on CommonJS require() syntax (I haven't seen this)
  • Could exclude users in environments where ESM support isn't available
  • Some older build tools and environments may not support ESM properly
  • Migration cost for existing projects using the library with CommonJS

Summary

From my experience from our down stream consumer (internal and ecosystem), most use ESM syntax. Most use modern frameworks w/ modern tooling, so the migrations shouldn't be too much of a problem IMO.

It'd make sense to do a PoC with the FE people to identify any obstacles arise. Did you have anything in mind for this?

@arboleya
Copy link
Member

arboleya commented Jan 6, 2025

@petertonysmith94 Great, thanks for the points. The Wallet would be a good start for a test like this. Should it be as easy as checking if an ESM-only package is already in use?

@petertonysmith94
Copy link
Contributor

So the wallet is already ESM complaint from what I know.

I believe the best test would be to publish our packages with only ESM bundled, then switch over the consumer.

@petertonysmith94 petertonysmith94 mentioned this issue Jan 6, 2025
Open
@arboleya
Copy link
Member

arboleya commented Jan 6, 2025

Graet! If the other apps (explorer, etc.) are also ESM-compatible we may be good to go (internally, at least).

Let's try to speak with @LuizAsFight to coordinate something.

@danielbate
Copy link
Member Author

Unassigning as I'm not actively developing this right now and lots of conversations happening, someone is welcome to pick this up.

@danielbate danielbate removed their assignment Jan 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
chore Issue is a chore
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@arboleya @danielbate @petertonysmith94