Webpack 2 (3)

[kettanaito]

Introduction

Webpack is undoubtedly one of the greatest things to handle JavaScript (any not only) bundling and serving for development and production environments.

Benefits

• Flexibility. You can configure the source and transformation chain (loaders, plugins) to process your files. Result: Easily adoptable to any project's needs.

• Performance:

  • Code splitting. Client downloads only that JavaScript code which is really needed at the moment. Result: No redundant downloads, faster page load time.
  • Tree shaking. Automatically analyzes the code and removed unused parts (including 3rd-party libraries). Result: Smaller bundle file size, faster page load time.
  • Varios optimizations (OptmiseJS, Gzip compression, Prepack). Result: More efficient

• DX:

  • Webpack development server. Provides Hot Module Replacement, which means your changes in JavaScript take place without page reload and loosing the application's state. Result: Faster development process, great DX.
  • Ability to separate vendor bundle (React, Redux, any 3rd-party modules) and client bundle (actual code of the application) and process them separately. Result: Faster initial and incremental builds, faster development process.
  • Simplified build pipeline. With Webpack it is possible to control multiple transformation pipelines of multiples file types (CSS, JS, Images, Fonts, etc.). Result: We can simplify our gulp tasks, remove unnecessary tasks which will be replaced by Webpack, and therefore keep our code cleaner and easier to understand.

• Extendability. It is possible to easily extend the configuration to bundle CSS, images, fonts, anything. It is also quite simple to create a separate configurations for client/server/vendor/any end-points.

Implementation

This is a rather big change, therefore it is separated into several waves of implementation. Each wave will be followed by pull request and code approval. This issue is regarding only JavaScript bundling as a starting point. We can always extend the configuration once we have it (Webpack can beautifully bundle CSS, images, icons, fonts, anything).

First wave

• Prepare dev-stack for Webpack
• Integrate Webpack into our Gulp pipeline
• Clean up current Gulp tasks which will be gracefully replaced by Webpack (js, lint, etc.)
• Validate and test optimal configuration setup
• Provide smart environment-specific configurations/extensions
• Provide basic loaders for everyday usage
• (Production) Introduce JavaScript optimization tools (OptimizeJS, prepack, Gzip)
• Introduce basic set of resolve.alias for utmost DX
• Introduce vendor.js bundle for third-party libraries (React, redux, younameit)
• Provide proper lazy initialization of JS modules/components for efficient code splitting

Second wave

• Document how to configure Webpack
• Document simplified adjusted workflow
• Test new configurations on real-scale projects (you can suggest in the comments)
• Test tree shaking
• Involve volunteers to test the changes

Third wave

• Implementing adjustments and suggestions from colleagues
• Optional code cleaning, configuration performance improvements

Motivation

I would like to use my experience with custom configurations of Webpack from side projects, Conrad, and countless articles and posts on the web. There are a lot of details, which, if not configured, or configured wrong, can cause a spectre of various issues during development and production.

Integration

In order to eliminate incompatibility issues, mentioned changes should be stored in the separate release of gulp-dev-stack repository, marking a new era of our dev-stack.

• You clone v1 by default
• You clone v2 when specified

This separation is definitely possible, feel free to suggest how it may be done if you did something similar in your repositories, otherwise I will just read the documentation of Git releases.

Additionally, choosing proper technology for your tasks is a great ground to end up with good implementation. Webpack is a great tool, yet it is still very likely that some projects will not get much benefit from it. This makes versioning even more important than ever.

Update from 23.06

This change has been approved as the part of ACTUM LAB. I will start on this as soon as I align with @DavidSlavik and my PM. Work in progress.

[fidelman]

@kettanaito If you need any help, I'm in a deal

[DavidSlavik]

Hello all,

we created "testing team" with @ronaldruzicka and @zmrhaljiri who will try if your version is ready for use. Hope that we will give you feedback very soon.

Thanks for your effort!

[DavidSlavik]

Please, update particular tasks by checking of checkboxes in your description.

[kettanaito]

@DavidSlavik hello.
Testing team sounds great! I would like to gather all the feedback I can get once the implementation is testable.

However, my project workload does not allow me to spend as much time as I would want to on this internal task. I have checked the steps I've done so far, apart from the research on the web (which is not a step itself). I do not find current state as testable.

I would appreciate some help in the major obstacle this implementation faces, as well as our projects in Actum face: what is an efficient way to split the code for non router-based applications?

We already had a quick discussion with @janpanschab during the team-building, and that was interesting. I like when people brainstorm and solve problems. This is how I see this problem solved as well.

[vbulant]

@kettanaito There seems to be some kind of non-route based code splitting in Next.js 3: https://zeit.co/blog/next3

[kettanaito]

@vbulant thanks for the link!
I am not very familiar with Next, yet from the things I've heart it is still based on routes. There are a few mentions of dynamic imports, which is good, but rather a flavor than a solution.

We can still use dynamic imports with Babel (maybe even without now), which resolves into a Promise. The code splitting always worked at the import point (it is not related to dynamic imports). Whenever Webpack encounters an require/import statement, it potentially creates a code splitting point.

I am thinking about organizing a small (1-1,5h) brainstorm for anybody who is interested regarding efficient code splitting point. We can come up with great ideas together :)

[kettanaito]

Update (16.08)

• Had a productive discussion with @ronaldruzicka about using the most from Webpack for production build to achieve optimal bundle size
• Had a small discussion with @bebraw (one of the members of Webpack core team) regarding code splitting for non router-based applications. I made a proposal to him to provide an example of this in his next presentation. He agreed.
• Currently analyzing pros and cons of having config extension over using completely separate configs for different purposes (app/vendor/etc.)

[kettanaito]

Update (17.08)

• Plan to investigate proper React bundling for production. It seems that webpack.DefinePlugin() and DLL bundle do not work well together (might be a Webpack bug)
• It would be good to quickly setup a minimal bundle aliases for webpack configuration

[kettanaito]

Update (30.08)

• Tested app/vendor bundling with a BundleAnalyzer, making app bundle size optimal, and do not contain any node_modules modules
• Provided the basics of reusable webpack configuration parts. After spending some time with the merging strategy of webpack configurations, I found out it is not very friendly when trying to achieve granular control over bundle's transformation pipeline. For this matter, separating transformers/processors into a separate reusable parts makes much more sense
• Preparing to finish the parts and start with the changes of the build pipeline

[kettanaito]

Update (25.09)

After some period I finally got time to spend on the task.

• Simplified internal bundling logic, made it more simple and, therefore, faster
• Introduced basic Production pipeline for app bundle:
  • Minification, top-level (safe) mangling
  • Dead code elimination (tree shaking)
  • Stripping React's propTypes
  • (Optional) Gzip compression (by passing --gzip in the CLI)
  • Optimization of code for faster execution in the browser
• Added environment propagation to vendor bundle (for the usage of development version of React, Redux, etc., as well as their production versions)
• Tested the changes above

Benchmarks

Just to give you a brief overview how these changes affect the final bundle size.

	Development	Production	Production (Gzip)
Before	1.1 Mb	346.4 Kb	Not available
After	21.8 Kb	4.91 Kb	1.69 Kb
Size reduction	~98.1%	~98.5%

Note: Client bundle size is also smaller because all 3rd-party dependencies are bundled into a separate file (vendor.js). This file is meant to be downloaded once and cached, well, forever.

[kettanaito]

Update (27.10)

• After almost a month of break I need to solve merge conflicts with the current master branch first
• In the current state webpack compiles all the necessary bundles separately. Now I will integrate proper gulp tasks into the build pipeline to automate the builds
• webpack-dev-server and HMR are in the scope as well

[kettanaito]

Update (13.11)

• (Past update) Resolved numerous merge conflicts with the latest master, mainly caused by dramatic structure changes of project's dependencies. The latter are now properly aligned, everything required by the app to run is moved into dependencies (this gets included into vendor.js automatically), everything needed for development - into devDependencies.
• Started the integration of webpack bundling profiles into our build pipeline
• Refined build pipeline
  • Introduced clear and intuitive build task, no ambiguous prepare
  • Aligned Gulp task names to one convention we use task:subtask (api-reload -> api:reload, tpl-compile -> tpl:compile). Following one convention, tasks are now predictable
• Refined configuration structure. I've introduced a configuration declaration pattern which is easy to use, read and maintain. It also dramatically reduces the amount of imported variables in the Gulp task files. (SVG_SPRITE_ALL -> SVG.SPRITES.ALL)
• Written the "webpack" article of the documentation