How We Bundle Delve Using Webpack

My name is Petar Paar and I’m an engineer working on Delve Web. I will show you how we build and bundle our front-end code and explain you how we transitioned to Webpack.

What is Webpack?

Webpack = Magic

In short Webpack is a tool which solves the problem of bundling modules with dependencies. In other words:

1. Input —> modules with dependencies (bunch of files of any type).
2. Webpack Magic —> processing and bundling all the modules and all related dependencies.
3. Output —> static bundled files built based on all dependencies (js, css, images, …).

How Webpack works

I won’t go into details how it works, instead I will show you how we use it and why we love Webpack. You can find more in official Webpack documentation and here.

How We Transitioned to Webpack

As Alex mentioned in his post, our app wasn’t built initially with React and all the related goodness, instead our plan was to transition our app gradually from our legacy technologies. Our initial decision was to replace JsMVVM (Microsoft internal MVVM framework) and Script# code with React components written in TypeScript. In order to integrate that we needed to introduce some kind of build process for the “new” stuff. As Script# has its own way of building and bundling we couldn’t integrate with it. To make things more complicated we had a part of code (data layer) written in TypeScript which used TypeScript compiler directly to build (this part of code didn’t have any external dependencies). We also knew that our app size was growing and that we needed to start demand loading more resources.

So we decided to introduce a new build process for the new stuff with idea to have “one build to rule them all”. We did some research and we decided to use Webpack as it provided all the functionalities we needed with awesome out-of-the-box features. After we introduced Webpack we really had a very complicated build process with 3 different separate builds (Script#, TypeScript, Webpack). We managed to make it simpler by moving our TypeScript data layer build inside of Webpack and using Script# build output JS files as one of Webpack inputs. We were happy with this as it enabled us gradual transition of our code. We were also able to quickly deliver performance improvements to our customers by demand loading resources without our entire app being Webpack built.

Why We Love Webpack?

When choosing what to use for building and bundling of our bits it was pretty clear that it will be Webpack as the community found that it was the most powerful bundling tool available and it still is!

What we love are out-of-the-box features you get for free:

• The most powerful feature is probably code splitting which enabled us loading resources on demand. This is the main reason why Webpack was built in the first place.
• It can handle and process any file type with a related loader. That also includes CSS which enabled us to use CSS modules and inline styles out-of-the-box. There are lots of loaders available here and if it doesn’t exist you can always write a custom one.
• Super robust — it can handle probably any possible scenario you can imagine (with configuration or/and custom plugins and loaders). I’m not saying it’s easy :-) For example, we solve our RTL CSS with postcss loader and custom postcss plugin.
• Assets hashing.
• Incremental building.
• Hot reloading with Hot Module Replacement.
• Integration of 3rd party libraries as modules.
• Handles the CommonJs and AMD module styles which are under the hood handled the same way (native ES6 coming with Webpack 2).
• Optimizations

What is also interesting are negative sides of Webpack. From our experience:

• Steep learning curve — there are really lots of possibilities with configuration and at first it makes people confused. Often people say it’s magic :D If you are starting with Webpack I would definitely suggest this link.
• Poor documentation when you need to do something that is not on the happy path. If you are new to Webpack you will probably spend some time to make things work.
• Sometimes “hacks” are needed to make things work — github / stack overflow can be helpful but sometimes things get messy.

How We Use Webpack?

I’ve put a starter pack on Github so that you can see how we’ve setup Webpack:

https://github.com/pepaar/typescript-webpack-react-flux-boilerplate

You can look at it as simplified version of what we use in production. The features are more or less the same. What you won’t see in this starter pack is how we integrated Webpack with MSbuild which we use in our main build process. We solved this by wrapping Webpack call inside of library project (.csproj) and using Exec task:

<Exec 
    Command=”$(Node_Path)\node.exe
    $(Npm_Path)\node_modules\webpack\bin\webpack.js 
        --output-path $(OutputDir)” 
    WorkingDirectory=”” 
    CustomErrorRegularExpression=”ERROR in” 
/>

Final thoughts

We have been using Webpack for a year now and we are very satisfied with it. It does its job and does it effectively. We’re looking forward to see Webpack 2 in action.

In next post we will explore why we use TypeScript so stay tuned!

If you find this interesting and you would like to work at Microsoft, we are hiring!