A build system for all SPA: Webpack

The intricate build system

First build it , then improve it and finally optimize it

I have always followed the principles of measuring the need before building something new. As developers, there is always an urge to work on the latest tech stack and this blinds people to adopt technologies which do not suit the product one is building. So when we first set out to develop our new UI and we needed to have a build system in place I went ahead with r.js since I already had been working on it and it was easy to adopt for the requirements at hand.

It has been one year now since the release of the new UI on yfret.com and our code base has grown considerably. We use react, backbone, j Query and a whole host of new libraries as and when the need arises. As anyone could assume, the code base started growing and managing our builds for production started becoming difficult. Cache busting, bundling files, chunkification were manually being done. We needed a solution to keep the front end sane and easy to maintain. So began our journey to relook at our build system and our needs altogether.

This post will be all about getting you started from basic to advanced by pointing you to various sources which helped me learn and use webpack, hopefully helping you master your way through this awesome tool.

Techies analysis:

Just like i usually do, first i had to define the end results expected out of the build system.

What we wanted to do ?

• Ease of bundling files
• Ease of handling packages and upgrading them
• Ease of cache handling so that only one bundles cache updates instead of reloading the whole app.
• Ease of using Es6 features without worrying about browser support.

Searching for solution:

As you would have it r.js was not up to the mark to handle all these with many manual configuration requirements. We had to look for a better and easy solution and what better then webpack to get this done.

Thanks a ton to Artyom Trityak for putting together a detailed post about moving from Requirejs to webpack. It helped me a great deal to move ahead fast.

Migration from Require.js to Webpack 2

Apart from the reasons mentioned by Artyom Trityak about him moving to webpack, here are some more which I could point out.

• I was manually bundling files together and had to take care of grouping files myself. Handling dependencies were not easy and I could only bundle vendor files
• With webpack adding dependencies was easy. npm can take care of all dependencies and everything from CSS to js is loaded as modules. In Requirejs i manually had to add css in my HTML file and js files were loaded with require. I usually would create a shim for it.
• For cache handling, i had a global cache busting require.config so even a small file change caused entire app to build and refresh. Webpack could do it by just creating a different md5 checksum for that bundle.
• Better maintainence of global variables to make sure that nothing is exposed globally by mistake
• So many plugins in webpack can make life easier to maintain code. Things like eslinting, css preprocessors, babel presets to support es6 features, all of them can be easily added.
• Since css is also loaded as modules, it becomes easier to reason about and also prevents polluting css which belongs to some other components.
• Upgrading to newer versions of libraries is easier.

Understanding Webpack:

While you are getting started with webpack, Its little difficult to grasp at first especially since the configuration can really become complicated. There are many good sources to understand them better. For me i always find it good to start with a sample project to know how to use webpack in general.

A quick search for webpack in youtube can land you to some really good tutorials enough to get you started with basics.

Here’s some videos by LearnCode.Academy and Traversy Medi which can get you started.

As you dive deep you will come across many things which might be confusing at first and will take some time to grasp. rajaraodv have done a great job of explaining the confusing parts of webpack.

Webpack — The Confusing Parts

Moving to Advanced:

After you fit webpack into your codebase and have a basic setup running. You then start diving deep to bring the maximum out of your webpack build.

Now your objectives would invovle:

• Code splitting
• Have a way to analyze the bundles created
• Optimize the bundles created for having maximum effeciency.
• Have seperate production and development builds.

Adam Rackis has a real nice post which can set you in the right path to build complicated setups.

Vendor and code splitting in webpack 2

Once you are done with code splitting and creating production builds you are still not done yet.

Now your objectives would evolve to handle the following things:

• Creating unique chunk-hash for each the bundles you created. (This is to allow for long term caching)
• Creating chunk manifest to map the bundles and make sure that correct file is being referenced.

Andrey Okonetchnikov has written in detail on how to achieve long term caching. Make sure you go through his post.

Long-term caching of static assets with Webpack

If you are done till here then tap your back, you have done a good job.

Overall Problems I faced while moving to webpack:

• I somehow could not get webpack 3 to work. It would not create bundles especially for async modules so I moved to webpack 2 instead. If you know a solution please post it over in the comment section.
• It took me a while to figure out loaders and how to use them.
• Took a while to understand long term caching. Had some problems with manifest plugins. Finally ended up using the inlinewebpackmanifest plugin.
• Could not get google charts to work so I’m loading it separately through script tag in our base HTML template.

Our Final Webpack config:

It may look overwhelming at first but once you understand it, it can be pretty easy.

Conclusion:

Webpack is very modular and everything is basically done by plugins. Based on your code, the setup can grow pretty complex. The idea is to learn one bit at a time and use each plugin based on your requirements.

Did i miss something?

Let me know your comments and suggestions.

Do you want to know more about YFret?

Our mission at YFret (Why Fret) is to use elegant programming and solid technology to build a super intelligent marketer’s best friend. Imagine a savvy e-commerce marketer with a tech “best friend” who can simplify his life as a data driven marketer. Go here to know more.

If you enjoyed this article, do show your support with a clap. Would mean a lot and it helps other people see the story too.

Read more of my blogs here.