Skip to content

Serve CSS and JS from Webpack - without Middleman rebuilds

Why is this change being made?

This MR enables hot reloading in our Webpack config.

To reduce overhead time, we can serve our Webpacked CSS and JS from Webpack's devServer.

However, in order to do this and avoid triggering Middleman builds, we have to instruct Middleman to ignore the source/javascripts, source/stylesheets, and Webpack output directories.

And since Webpack devServer serves assets from memory, they don't get written to disk in a way that Middleman can access from its local development server.

To keep the dev commands and interface the same, I set up a proxy through Webpack devServer, so when we type:

NO_CONTRACTS=true bundle exec middleman

It starts a Middleman server on port 7654, and a Webpack devServer on port 4567, to mimic the old behavior. Webpack proxies everything to 7654, so the assets it handles get served properly from Webpack, and all the Middleman output gets served from Middleman.

This introduces a bit of complexity into the config files, but they had a good surface area for it. The block that executes based on the SKIP_EXTERNAL_PIPELINE env variable provides a place where we can contain this change. This means no one has to change their workflow (many people won't even know or notice this happens), and there's a good escape hatch if we change SSGs or configuration.

If we wanted to do something a little more direct, we could keep everything the same, and ask people to run a second server in an additional terminal window to serve up Webpack assets. But since we can't bind both that server and Middleman to the same port, we would have to conditionally point Middleman assets to localhost:some-webpack-port based on the environment, and these assets are spread throughout the repo.

When we end up getting to bundling the assets with webpack, that might be a piece of cleanup we can do, since we can drop a bundle tag in the main template and do some work based on environment variables.

Author Checklist

  • Provided a concise title for the MR
  • Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what
  • Assign this change to the correct DRI
Edited by Tyler Williams

Merge request reports