This series of posts will explain how to utilise the power of the Webpack module bundler with an existing (or perhaps new) Durandal application. But first...

A bit of background

Durandal is a mature SPA framework built atop popular existing libraries: Knockout.js, Require.js and jQuery. It allows users to use a modular, MVC-like approach to SPA development, via it's extensive use of Require.js. This is a great starting workflow, allowing users to quickly create applications with little to no boilerplate outside Durandal itself, which lends itself well to agile development environments.

Webpack is "module bundler", which allows users to take a given set of modular JavaScript files, and compile them down into a single (or multiple) file(s). Not only that, but it also allows us to bundle in other file formats such as CSS and HTML via the use of module loaders. This effectively allows us to represent the whole application as a single, pre-built, minified file, assets and all. Perfect for production environments that need extensive caching and minimal network activity!

Using them together

Durandal already supports bundling your app via the r.js bundler, but it's more than possible to utilise the advanced features of Webpack in place of this, and gain a lot more freedom in the process, particuarly relating to bundling other CSS and HTML assets!

One exciting possibility is the use of ES6/7 code within your Durandal application via the use of Babel and Webpacks babel-loader which, while not covered in this blog series, is an exciting step forward for developers and applications alike. Make sure to look into this!

Okay... then how?

Using Webpack with Durandal requires some changes not only to our code, but to our workflow. Durandal was originally designed for use within an AMD environment, as opposed to the CommonJS approach those of you with Node.js experience will be familiar with. We'll need to adapt our existing code to fit within this CommonJS syntax, and hopefully make things more readable in the process!

Along with this, we'll need to monkey-patch Durandal's internals with some additional functionality, which will let us use static dependencies for our Views, Dialogs, and Router(s). Don't worry, this functionality is entirely backwards compatible, and can be used for new features going forward, whilst still maintaining compatibility with old code!

Show me the money!

If you're a code monkey and prefer to dredge through the code yourself, checkout the durandal-webpack GitHub repository, as well as the Online examples produced via it's gh-pages branch.


Next Chapter: Durandal and Webpack: Part 1 - Module Format