Forem: Ronni Egeriis Persson

On NPM Packages and Bundle Size Impact

Ronni Egeriis Persson — Wed, 12 Jun 2019 20:35:36 +0000

Edit, June 13, 2019: What a timing... pika.dev have just been released, which is a CDN for ES modules. Their search engine also reveals which packages does not have an ES module entry, try searching for moment.

We've got a bundle size problem, and the heaviest objects of the universe carry a lot of blame. Here's a quick write up on the matter that I hope can spur some debate.

Emphasis on web app bundle size keeps increasing, which means that a lot of frontend engineers eyes are aimed at a search for things to exclude, tree shake, replace, lazy load, ... from their build output. But there's an elephant in the room, that no-one seems to be talking about: NPM packages and their distribution format.

Some background on tree shaking and ES version in NPM before we dive in.

Tree Shaking

Tree shaking is one of the key ingredients to keeping your application bundle size to a minimum. It's a mechanism used by bundlers like Webpack to remove unused pieces of code from dependencies. This is something that the bundlers can easily determine for ES modules (i.e. import/export, also known as Harmony modules), since there can be no side-effects.

It is not supported for CommonJS nor UMD modules. And this is the important piece of information you need.

ES2015+ in NPM Packages

Most frontend engineers prefer to use modern ES features like ES modules, fat-arrow, spread operator, etc. The same is true for many library authors, especially those who are writing libs for web. This leads to the use of bundlers to produce the output which is published to NPM. And this is where we have a lot of potential for optimization.

Casting a quick glance over some of the most depended upon packages in NPM reveals that a lot of them are publishing CommonJS modules only. In a big project I'm working on, we've got 1,773 NPM packages in node_modules, just 277 of these refer to an ES module build.

A Problem Shaping Up

Let's outline the problem here:

How many NPM dependencies does your app have? Likely a lot.
Does your app use 100% of the code in those dependencies? Very unlikely.
Can your bundler tree shake those unused code paths? Unlikely.

This problem is even recognized by the most depended upon package, lodash, who's authors publish a specific ES module output as lodash-es. This is great, as it allows us to use an optimized build of lodash, which can be tree shaken and wont include unused code in our app build.

But this seems like an afterthought, better solutions are readily available and many popular libs does not offer a ES module build.

Problem Illustrated

To illustrate the problem outlined above, I've initialized a simple reproduction here.

`math`

math is a small library with two exports, cube and square. I've set up rollup to produce both CJS and ES module output.

`app`

This contains a small app which is bundled using webpack. It consumes 1 function from math and correctly tree shakes the unused export from it's output.

`node`

A small proof that the output of math also works in Node.js-land with require.

Outcome

While this is a very small example, an impact on app bundle size is imminently visible when toggling between CJS and ES module output.

Production build size with ES module is 1.1kb:

            Asset     Size  Chunks             Chunk Names
  bundle.index.js  1.1 KiB       0  [emitted]  index

While it's 1.16kb with CJS and no tree shaking:

            Asset      Size  Chunks             Chunk Names
  bundle.index.js  1.16 KiB       0  [emitted]  index

Negligible difference for this teeny example, but the impact can be significant once you consider all the heavy objects in your node_modules folder.

Problem Solved

In our example above, we have managed to find a simple solution this problem. Our dependency math can be used in both Node.js and bundler-land (and browser land, if you target modern browser), and it's simple to achieve.

How It Works

If you bundle your app with a bundler that supports tree shaking (Webpack 2+, Rollup, and more), it will automatically resolve your dependencies' ES module if present. Your bundler will look for a module entry in a depency's package.json file before defaulting to main. Take a look at math's package.json for an example:

{
  "name": "math",
  "version": "1.0.0",
  "main": "index.js",
  "module": "indexEs.js",
  "devDependencies": { ... }
}

Pretty simple. math has two output destinations, one is a CJS module (index.js), another a ES module (indexEs.js).

One Gotcha

I've had a library published for a while, which used this approach, and many users have been confused because it's been best practice to ignore node_modules in Webpack for a long time. To utilize tree shaking, Webpack must be able to read dependencies' ES modules, so if you require backwards compatible app build, you should also transpile these dependencies in your app build step. This is good if you prioritize bundle size over build time.

Call for Action

Library authors, please consider adding a module entry to your package.json and start producing an ES module version.

Generic typing of Redux modules in Flow

Ronni Egeriis Persson — Mon, 09 Apr 2018 17:18:01 +0000

While the official Flow docs present a solution to typing Redux modules, the way their example is designed implies copy/pasting the type definitions into each of the Redux modules. This is not optimal.

Let's examine their example:

type Action =
  | { type: "FOO", foo: number }
  | { type: "BAR", bar: boolean };
type ThunkAction = (dispatch: Dispatch, getState: GetState) => any;
type PromiseAction = Promise<Action>;
type GetState = () => State;
type Dispatch = (action: Action | ThunkAction | PromiseAction) => any;

Looking at the first three lines in above snippet, we see that their example has a static set of action types specified. This exposes an issue in applications where the state is spread into multiple modules, leading to duplicate code or other code smell.

Using the method from above snippet in such application, we have to either:

Specify the types top-level and provide them access to all action types of our application
Copy/paste these type definitions for each Redux module—or, rather, the level at which you split your action types

Both of these solutions lead to code smells.

Making Types Generic Using Generics

So how do we create these types in a generic way? Using generics!

Remember, the main problem in the original code is that the type Action is static. Essentially, all we need to do is to make that value variable.

Here's my solution:

export type ThunkAction<S, A> = (
  dispatch: Dispatch<S, A>,
  getState: GetState<S>
) => any;
export type PromiseAction<A> = Promise<A>;

export type GetState<S> = () => S;
export type Dispatch<S, A> = (
  action: A | ThunkAction<S, A> | PromiseAction<A>
) => any;

Whoah, that's a lot of generics!

Yeah, I know. But it's really not that complex:

For the purpose of following Flow's own practices and for brevity, generics are named by one letter. A stands for "Action" and S for "State". These are the two types that we have to make variable, because they're different for each Redux module.

Using generics we can require "arguments" to be passed where the types are used. Referring my solution, ThunkAction requires two "arguments" to be passed, State and Action, so defining a thunk action could look like this:

type FetchFooActions = ActionFoo | ActionBar;
function fetchFoo(): ThunkAction<State, FetchFooActions> {
  return (dispatch, getState) => { /* inside my mind I have a digital mind */ };
}

State is the type definition for the state of our Redux module, and FetchFooActions is a clear specification of the actions that are expected to be dispatched from calling fetchFoo.

If you need to use PromiseAction, GetState or Dispatch, simply supply those with their generics "arguments":

// Supply your State and Action types to Dispatch, State only to GetState
const cb = (dispatch: Dispatch<State, Action>, getState: GetState<State>) => { ... };
// Supply Action type to PromiseAction
function asyncAction(): PromiseAction<Action> { ... }

We have now untangled the four types, ThunkAction, PromiseAction, GetState and Dispatch, so they can be shared across the application without code smell. But we even enabled ourselves to be more specific in our typing simultaneously. You can see this by attempting to dispatch an unexpected action in my full example:

Full example on flow.org/try

I hope this is valuable inspiration. Feel free to comment or ask questions :)

Hi, I'm Ronni Egeriis Persson

Ronni Egeriis Persson — Sun, 19 Feb 2017 20:18:35 +0000

I have been coding for 21 years.

You can find me on GitHub as egeriis

I live in Copenhagen, Denmark.

I work for Dixie, which I've co-founded.

I mostly program in these languages: JavaScript & PHP.

I am currently learning more about websockets and automatic updating of Redux state.

Nice to meet you.