FYI: Phoenix drops webpack and npm for esbuild

The Phoenix Framework is the go-to web framework for Elixir developers. A recent PR was merged that replaces the use of node, npm, and webpack with esbuild.

For those new to esbuild, it is written in Go so it compiles to native code and runs really fast. It is a JavaScript bundler that performs many common asset pipeline tasks.

To understand why the change happened, it’s good to get a sense of the problems the Phoenix team has been dealing with.

Of the Phoenix project’s 2,034 total issues, npm was involved in 591, webpack played a role in 79, and brunch was a factor for 171.

Some of the issues overlapped into multiple areas, so we can safely say that around 30% of reported Phoenix issues were related to JavaScript packaging! That’s a lot of issues to support and they aren’t even for the language the framework is written in!

Chris McCord, the creator and maintainer of Phoenix had this to say:

I say this in the fairest way possible after years of support & churn – I now consider placing the burden of node/npm/webpack on new users as actively harmful. Also, long-term reproducible builds are essential for maintainable software & node has not stood this test of time. With esbuild, those that want to take advantage of the innovation in the node community need only to npm install and esbuild will handle it, so the opt-in path is as simple as it gets when folks are doing complex client-side development that necessarily involves node tooling.

This change allows newcomers a seamless getting started experience, long-term moderate js/css users a rock-solid reproducible build for the lifetime of their projects, and advanced client-side SPA users a trivial opt-in path. So esbuild allows us to execute on all fronts!

If your team does a lot of front-end javascript, you likely have your own customized setup using webpack or other tools anyway. The Phoenix change to esbuild does not prevent you from using whatever asset processing tools you need.

Speaking of the esbuild change, José Valim, the creator of Elixir said:

This matters because it gives us full ownership of the getting started process. If someone runs the phx.new installer for v1.6 in 5 years from now, they should still get a fully functional project.

In the last weeks, phx.new has been broken because of node-sass and then npm v7. Plus other reasons in the past. We always have to catch up.

It is extremely important that your first ever Phoenix command always succeeds, and this gets us very close to that!

Interested in trying it out right now? José Valim explains how:

If you are moving an existing project, then running [Phoenix] v1.6 should be totally fine.

If you want only esbuild, you don’t need to move to v1.6 (see example), but remember esbuild can still leave zombie processes until a PR is merged upstream.

The change to esbuild will be part of the upcoming Phoenix 1.6 release which is expected “soon”. As the Phoenix release nears and more people are trying it out, we’ll get a better sense of any snags or migration issues.

This is an exciting change! Over the years, I’ve fought many times with broken JS build pipelines because some dependency updates were needed. I’m very interested in seeing if this meets the goal of being a more stable system over time.