Switching an existing Phoenix app from Brunch to Webpack

by Atul Bhosale,

Phoenix version 1.4 onwards will be using webpack as a module bundler for javascript. This blog post is about the steps which I followed to switch from brunch to webpack in an existing Phoenix project.

Clone Phoenix

Since Phoenix 1.4 is unreleased as of when this blog is published, we will generate a new project using Phoenix source installer. Clone Phoenix and run -

cd phoenix/installer
mix phx.new dev_app --dev

Run npm install in dev_app/assets folder.

Copy this assets folder to the existing Phoenix project folder which we want to switch from brunch to webpack.

Delete brunch config

Delete brunch-config.js, package-lock.json & node_modules folder. Copy required dependencies from existing package.json to package.json file in assets folder except for brunch related dependencies like brunch, babel-brunch etc. Delete package.json from the root folder.

Run npm install after adding the dependencies to the new package.json file.

Copy js & css files from static folder

Copy js & css files from web/static folder to assets/js & assets/css folder & delete web/static folder.

Delete default styles used for starter applications

Delete assets/css/phoenix.css & its entry from assets/css/app.css

Update npm watch script

Update npm watch script in assets/package.json to --

"watch": "webpack --mode development --watch-stdin"

Using --watch-stdin option exits the nodejs process when stdin(standard input) is closed.

Update webpack watcher config

Update webpack watcher config in config/dev.exs to --

watchers: [node: ["node_modules/webpack/bin/webpack.js", "--mode", "development", "--watch-stdin",
  cd: Path.expand("../assets", __DIR__)]]

Add to .gitignore

Add node_modules under assets to .gitignore

/assets/node_modules

Update babel presets

Update babel presets which are required in the project.

{
  "presets": [
    "env",
  ]
}

Start Phoenix and check webpack

Start Phoenix with -

iex -S mix phx.server

and check if webpack has built the js bundle.

Here is the reference PR and discussion.

More articles

Operating Kafka in Rails with Karafka: Production Architecture, Consumers, and DLQs (Part 2)

In Part 2, we dive deep into the Sync-Out pipeline—how Rails publishes events to Kafka, how our legacy adapter writes to SQL Server 2009 using TinyTDS, and how Dead-Letter Queues (DLQs) became our lifeline during production incidents. This post covers transaction management, service objects, and operational workflows for handling failures.

Read more

Operating Kafka in Rails with Karafka: Production Architecture, Consumers, and DLQs (Part 1)

This post breaks down our production architecture for event streaming in Rails using Kafka and Karafka—from designing producers and consumer flows to handling failures with DLQs and keeping warehouse databases in sync reliably.

Read more

Ready to Build Something Amazing?

Codemancers can bring your vision to life and help you achieve your goals