Webpack: from 0 to 2
- 1. Webpack: from 0 to 2(.3.3) Milano_JS 04.04.2017
- 2. Alessandro Bellini frontend developer @ Spryker - web: ilmente.com - github: github.com/ilmente - twitter: @ilmente
- 3. Agenda - grunt, gulp and webpack - webpack modules - entry points - loaders and plugins - configuration - code overview - code splitting - code overview - tree shaking - code overview
- 4. in the beginning it was grunt
- 5. grunt - focus on configurations - built around a set of built-in commonly used tasks - extension using plugins - each plugin has its own custom configuration - every task is an array of different plugin configurations, that simply get executed one after another, in a strictly independent, and sequential fashion https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4
- 7. gulp - focus on code - micro-tasks connected to each other (agnostic about their nature) - extension using plugins - plugins use API to be programmed - streams and pipelines https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4
- 9. grunt - focus on configurations - built around a set of built-in commonly used tasks - extension using plugins - each plugin has its own custom configuration - every task is an array of different plugin configurations, that simply get executed one after another, in a strictly independent, and sequential fashion https://medium.com/@preslavrachev/gulp-vs-grunt-why-one-why-the-other-f5d3b398edc4
- 10. grunt webpack - focus on configurations - built around a set of built-in commonly used tasks - extension using plugins - each plugin has its own custom configuration - every task is an array of different plugin configurations, that simply get executed one after another, in a strictly independent, and sequential fashion close, but it’s not exactly like this...
- 11. grunt webpack - focus on configurations - built around a set of built-in commonly used tasks features - extension using plugins and loaders - each plugin/loader has its own custom configuration - every task compile process (or step) is an array of different plugin loaders (eventually configured/extend using plugins) configurations, that simply get executed one after another, in a strictly independent, and sequential fashion - loaders can be chained together: this is helpful for applying multiple transformations to a file in a pipeline https://webpack.github.io/docs/loaders.html (webpack 1.x docs)
- 12. grunt - gulp - webpack - grunt and gulp are task runners - webpack is a module bundler - gulp and webpack are not necessary enemies You can use webpack with grunt/gulp: - https://webpack.js.org/guides/task-test-runner/ (almost useless page) - http://webpack.github.io/docs/usage-with-grunt.html - http://webpack.github.io/docs/usage-with-gulp.html
- 14. webpack modules not just modules
- 15. modules - discrete chunk of functionality a program is broken into - abstraction - single responsability - reusability - better debugging and testing
- 16. webpack modules - a dependency expressed by: - import (es2015) - require() (CommonJS) - define() and require() (AMD) - @import (css/sass/less) - url() (stylesheet) - <img src=””> (html) (!) Please refer to https://webpack.js.org/concepts: it’s well done and explained
- 17. entry points the root of the tree
- 18. - root of the tree
- 19. loaders and plugins is this a kind of magic?
- 20. loaders - functions - transform the source code of a module - synchronous or asynchronous - can be configured with options - can be chained - can emit additional arbitrary files https://webpack.js.org/concepts/loaders
- 21. plugins - webpack backbone - “anything else that a loader cannot do” (cit.) - it’s wizardry - can you do everything? - may I have a coffee? - hooks into the whole webpack build system - allow you to access, change, extend any phase of the build process, from resolving a module to bundling the output https://webpack.github.io/docs/plugins.html
- 22. in a nutshell - if you want to tell webpack how to load that specific type of resource: use loaders - everything else: use plugins
- 23. in a nutshell - if you want to tell webpack how to load that specific type of resource: use loaders - everything else: use plugins - if you want to change how this module is resolved and compiled: use plugins
- 24. a real configuration let’s switch to the code
- 25. code splitting introducing performance superheroes
- 26. code splitting - it’s a features - split your code into various bundles - smaller bundle size - resource load prioritization control - on-demand loading - may have significant performance impact - on build/rebuild time - on application/site load time - you have the freedom to choose and implement your own strategy to optimise the assets management https://webpack.js.org/guides/code-splitting/
- 27. - root of the tree
- 28. code splitting superheroes - css - style-loader - ExtractTextWebpackPlugin - vendor - CommonsChunkPlugin - on-demand - import() - require.ensure() https://webpack.js.org/guides/code-splitting/
- 29. tree shaking bullshit, myth or shut-up-and-take-my-money feature?
- 30. tree shaking - positive selection of actual used code (live code) - in opposition to dead code removal (UglifyJs plugin) - introduced in bundlers world by github.com/rollup/rollup Known limitations for webpack: - static structure - relies on es2015 module import/export https://webpack.js.org/guides/tree-shaking
- 31. the code said… - babel: - use preset babel-preset-es2015 with { “modules”: false } - use plugin babel-plugin-syntax-dynamic-import - limited to es2015 source code - unable to shake objects or inside statements - capable of dropping functions, but not classes - uglifyJS plugin needed
- 33. thanks yes, it’s finally over…