DEV Community

📦 webpack secrets

Nick Taylor on January 01, 2019

What webpack secrets or less commonly known features do you know? This also includes loaders or plugins that not everyone might be aware of. Please...

Read full post

Dane Hillard • Jan 1 '19

webpack-shell-plugin allows you to run arbitrary shell commands as part of your build. We've used this for a couple of complicated file-moving maneuvers that webpack would've otherwise choked on a bit.

Nick Taylor • Jan 1 '19

Thanks for the share Dane! This looks very handy.

Ankit Utekar • Jan 21 '19 • Edited

webpack bundle analyzer
It's a cool tool which generates a zoomable tree map showing what's inside your JavaScript bundle - size of each dependency ( and dependencies of dependencies recursively ) in minified, un-minified and gzipped format.
Setup is fairly simple, do give it a try.

webpack-contrib / webpack-bundle-analyzer

Webpack plugin and CLI utility that represents bundle content as convenient interactive zoomable treemap

Webpack Bundle Analyzer

Visualize size of webpack output files with an interactive zoomable treemap.

Install

# NPM
npm install --save-dev webpack-bundle-analyzer
# Yarn
yarn add -D webpack-bundle-analyzer

Usage (as a plugin)

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}

It will create an interactive treemap visualization of the contents of all your bundles.

This module will help you:

Realize what's really inside your bundle
Find out what modules make up the most of its size
Find modules that got there by mistake
Optimize it!

And the best thing is it supports minified bundles! It parses them to get real size of bundled modules And it also shows their gzipped sizes!

Options (for plugin)

new BundleAnalyzerPlugin(options?: object)

Name	Type	Description
`analyzerMode`	One of: `server`, `static`, `json`, `disabled`

…

View on GitHub

Nick Taylor • Jan 21 '19

Yeah that's a great one. We have it setup on react-slingshot. 🔥

Nick Taylor • Jan 2 '19

For those using TypeScript, the Fork TS Checker Webpack plugin is a must for any somewhat large project.

It allows you to run the TypeScript type checker in a separate process which results in faster builds.

TypeStrong / fork-ts-checker-webpack-plugin

Webpack plugin that runs typescript type checker on a separate process.

Fork TS Checker Webpack Plugin

Webpack plugin that runs TypeScript type checker on a separate process.

Features

Speeds up TypeScript type checking and ESLint linting (by moving each to a separate process) 🏎
Supports modern TypeScript features like project references and incremental mode ✨
Supports Vue Single File Component ✅
Displays nice error messages with the code frame formatter 🌈

Installation

This plugin requires minimum Node.js 10, Webpack 4, TypeScript 2.7 and optionally ESLint 6

If you depend on Webpack 2, Webpack 3, or TSLint 4, please use version 3 of the plugin.
If you depend on TypeScript >= 2.1 and < 2.7 or you can't update to Node 10, please use version 4 of the plugin.

# with npm
npm install --save-dev fork-ts-checker-webpack-plugin
# with yarn
yarn add --dev fork-ts-checker-webpack-plugin

The minimal webpack config (with ts-loader)

// webpack.config.js
const ForkTsCheckerWebpackPlugin = require

…

View on GitHub

Where I used to work, we had a very large project and it brought down the initial webpack build time from 2 minutes to 25-30 seconds.

And it looks like they also have an alpha out for webpack 5.

Liquid error: internal

JD Gonzales • Feb 7 '20 • Edited

This is very edge-case & specific but I spent days on this problem.

If you compile your assets on multiple servers and use @svgr/webpack, sometimes it can build 2 different hashes for a single compiled js asset, based on some attributes (or empty attributes) in svg elements, which causes inconsistent bundle names across multiple servers who all run the build step on their own. This causes unfortunate bundle app-[hash].js not found errors on the client side.

The trick to solving this is to disable svgo

test: /\.(svg)$/,
use: [
  {
    loader: '@svgr/webpack',
    options: {
      svgo: false
    }
  }
]

Thomas Lefebvre • Jan 3 '19

I usually find maintaining webpack configurations difficult. With either splitting prod and development configs or conditionally do some stuff based on an environment, that can get messy real quick.

I've been using the following for configuring some parts based on the environment for instance. I feel it has been keeping most of the config terse and easier to read.

kentcdodds / webpack-config-utils

Utilities to help your webpack config be easier to read

webpack-config-utils

Utilities to help your webpack config be easier to read

The problem

Webpack configuration is a JavaScript object which is awesomely declarative. However, the webpack config file can easily turn into an imperative mess in the process of creating the configuration object.

This solution

The goal of this project is to provide utilities to make it easier to compose your config object so it's easier for people to read. It has some custom methods and also comes bundled with some other projects to expose some helpful utility functions.

Installation

This module is distributed via npm which is bundled with node and should be installed as one of your project's devDependencies:

npm install --save-dev webpack-config-utils

Usage

It is expected that you use this in your webpack.config.js file.

Protip: You can name your config file webpack.config.babel.js and it'll be automagically transpiled! (Make sure you have babel-register installed.) So you could…

View on GitHub

Nick Taylor • Jan 3 '19 • Edited

Thanks for sharing Thomas. 🔥 Is there anything Kent C. Dodds can't do? 😂