task(many): Use esbuild in production #15112
Conversation
Because: - We want to move forwards with using esbuild in production This Commit: - Adds an ADR for using esbuild in production
| ## Decision Outcome | ||
|
|
||
| After a decent amount of discussion, we have decided to switch over to esbuild for our production builds. Other | ||
| teams have made the switch and not encountered major issues. |
There was a problem hiding this comment.
What other teams is this referring to?
There was a problem hiding this comment.
Not sure about plural, but I know the Firefox Monitor team switched to esbuild for their big v2 redesign. Amri did a good demo of their new tech stack in a recent 5x8 presentation a couple weeks ago (that I can probably dig up on AirMo if you are interested).
There was a problem hiding this comment.
Maybe the plural is misleading. I'll qualify this. And yes, I was referring to the Firefox monitor team.
There was a problem hiding this comment.
There are others, but we definitely seem to be pioneers: https://github.com/search?q=esbuild+user%3Amozilla+path%3A**%2Fpackage.json+lang%3AJSON&type=code
@clouserw might also have more context since I think he was speaking w/ the Monitor team and possibly others.
There was a problem hiding this comment.
I was talking with Amri: https://mozilla.slack.com/archives/CEV7MGSQH/p1678894690315309
There was a problem hiding this comment.
I'm for it since we won't be skipping typechecks. We should also consider using something like https://github.com/rsms/estrella instead of esbuild directly.
Agreed. TSX would be my suggestion. |
"tsx is designed to be a drop-in replacement for node". Not quite the same as replacing |
|
@chenba @julianpoy, I like the notion of using something like TSX or Estrella. I don’t think we need to come to a decision in this ADR, as these feel more like implementation details that can be decided on when speccing out the epic and might require a bit more evaluation anyways, especially when NX is thrown into the mix. They are duly noted though. It’s worth mentioning that these packages would also compete with esbuild-register. TSX seems to have good traction, Estrella not nearly as much. I’d certainly be in favor of using tsx over esbuild-register as it seems more full featured: https://npmtrends.com/esbuild-register-vs-estrella-vs-tsx I do have some concerns with Estrella’s project activity. It’s github repo hasn’t seen a commit in almost two years, despite having some seemingly reasonable PRs like this: rsms/estrella#58 |
Oh, good point. I didn't notice that. |
Yep, it's not. I'm advocating for us not pre-building our backend TS.
Agreed!
esbuild-register definitely has it's quirks and isn't really an "officially" supported way of using ESBuild. TSX can be either used standalone, or as a module loader similar to how esbuild-register works currently. @chenba the nice thing about using something like TSX is any of our stack traces would be shown with TS content and the proper line numbers even if things like interfaces are present in the code which get deleted by TSC. |
@julianpoy ok just so I understand fully, you are suggesting that we ship our ts with tsx for production instead of shipping the compiled js in the Docker image liek we do now? |
@chenba yep! |
Because
This pull request
Issue that this pull request solves
Closes: FXA-5960
Checklist
Put an
xin the boxes that apply