November 6, 2018 Ryan Weaver

After months of community work, I'm am thrilled to be able to talk about the release of Webpack Encore 0.21.0. This represents a huge step forward to stay with the latest versions of industry-standard tools and a bunch of great features along the way.

So, what changes and improvements happened? Let's find out!

Webpack 4, Babel 7 and Major Upgrades¶ The main focus of this release was to upgrade Encore to use the latest versions of Webpack & Babel. Webpack 4 contains a long list of improvements - like faster build times and a new way to "split" your built files into more optimized pieces (more on that later). Babel 7 is also a huge release - it contains optimizations and support (via @babel/preset-env ) for browserslist (more on that later). Several other libraries were also upgraded - see the CHANGELOG for full details. If you're using Encore's features exclusively, you shouldn't have any problem with these major version upgrades. If you've added custom features - be sure to check the changes for each library.

New runtime.js File¶ This version of Encore also introduces an optional new output file called runtime.js . You should explicitly enable or disable it by calling either enableSingleRuntimeChunk() or disableSingleRuntimeChunk() . If you enable it, a new runtime.js file will be output and needs to be included in your page (but encore_entry_script_tags() will handle this automatically) What's the point of runtime.js ? Suppose you include multiple entry JavaScript files on the same page - like an app.js in your layout and also checkout.js when you're on a checkout page. Then: With enableSingleRuntimeChunk() : if the same module (e.g. jquery ) is required by both entry files, they will require the same object.

: if the same module (e.g. ) is required by both entry files, they will require the same object. With disableSingleRuntimeChunk() : if the same module (e.g. jquery ) is required by both entry files, each will receive a different object. Using enableSingleRuntimeChunk() will give you the same behavior as Webpack 3, but you can choose whichever setting works better for your app.

New copyFiles() Feature¶ One of the most-asked-for features in Encore is the ability to copy static files into your build directory. Until now, we recommended using the copy-webpack-plugin. This plugin is great, but if you used version hashes in your filenames, the manifest.json file would not contain the correct key for this copied file (the key would be the versioned/hashed filename). In practice, this made it impossible to version your copied files with filename hashes. To fix this, Encore now has a copyFiles() method! It's simple: use it to copy files from one directory (e.g. assets/images ) into your "build" directory. If versioning is enabled, all files are given version hash names and are included in manifest.json so you can fetch the correct filename via the asset() function in Twig.

Async Code Splitting out-of-the Box¶ Did you know that Webpack allows you to require modules asynchronously, only when you need them? The feature is called Code Splitting. It's not new, but in the latest version of Encore, you can use it without any extra configuration: 1 2 3 4 5 6 7 $ ( '.js-open-video' ). on ( 'click' , function () { // async load the VideoPlayer module import ( './components/VideoPlayer' ). then (({ default : VideoPlayer }) => { // once it loads, use it! const player = new VideoPlayer ( 'some-element' ); }); });

browserslist Support¶ There are several tools in Encore that need to know what versions of browsers your site needs to support. For example, both Babel and autoprefixer (from PostCSS) will compile your code differently if you need to support older browsers versus only newer browsers. Until now, there was no one place to configure this. But, thanks to upgrades to @babel/preset-env , you can now set your browsers via a browserslist key in package.json . For more details, see the browserslist documentation for Encore.

Support for Uglifying ES6 Code¶ Before this release, Uglify (the library that minifies your JavaScript for production), was unable to process ES6 code. This meant that you were forced to transpile all your JavaScript to ES5 code, even if your site didn't need to support older browsers. Because of this, Uglify was replaced with terser - a fork of Uglify that processes ES6 code. You shouldn't notice any difference in your app unless you use the configureUglifyJsPlugin() method (use configureTerserPlugin() now).