Interlude: Let's talk about module systems

Two most common module systems in JavaScript

• CommonJS

• ECMA Script Modules (ES Modules)

CommonJS*

// In circle.js
const PI = Math.PI;
exports.area = (r) => PI * r * r; exports.circumference = (r) => 2 * PI * r;

// In some file
const circle = require('./circle.js');
console.log( `The area of a circle of radius 4 is ${circle.area(4)}`);

*Technically this is Node's take on CommonJS

CommonJS

• Designed with server development in mind
• require() can be called anywhere
• Synchronous API makes it not suitable for client-side
• Hard to analyze for static code analyzers

Source: https://auth0.com/blog/javascript-module-systems-showdown/

ES Modules

//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) { return x * x; }
export function diag(x, y) { 
  return sqrt(square(x) + square(y));
}

//------ main.js ------
import { square, diag } from 'lib'; console.log(square(11)); // 121 console.log(diag(4, 3)); // 5

ES Modules

• Support for static analysis tools
• Synchronous and asynchronous loading supported*
• Supported in modern browsers (no IE11)
• Only supported in Node JS 8.5+ with *.mjs file extension and ---experimental-modules runtime flag

Source: https://auth0.com/blog/javascript-module-systems-showdown/

Async import is Stage 3

math-lib

Part 1

CommonJS

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example01-cjs

• The library doesn't require any build system
• The library works out of the box with Node
• The browser gets all code including unused modules ☹️

What we learned

Part 2

CommonJS "Optimized"

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example02-cjs-optimized

• When using CommonJS, requiring in the direct module can help optimize client-side bundles
• This is why you should import lodash modules directly
  import get from 'lodash/get';

What we learned

Part 3

Bundling ES Modules with Webpack

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example03-es-with-webpack

• While Webpack is great as an application bundler, it isn't optimized for libraries
• Yes, Rollup would be better in this case

What we learned

Part 4

Convert ES to CJS Modules without bundling

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example04-es-to-cjs

• Webpack as an application bundler supports multiple ways of loading modules as specified in a library's package.json
  • "main" - meant for Node environments 
  • "module" - optimized for ES Module supported environments
• Don't bundle libraries with Webpack; instead transpile (with Babel)

What we learned

Part 5

Tree shaking classes?

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example05-classes-dont-optimize

• Classes are not well suited for tree shaking
• If you're worried about the impact of your library on bundle size (and you probably should be), use functions over classes

What we learned

Part 6

Side effects

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example06-side-effects

• Static properties on classes or functions can cause side effects
• Anything that may cause a side effect will automatically be included in your bundle even if you don't explicitly import it

What we learned

Note: This is where Rollup failed me in my own attempts at optimizing Stencil.

Part 7

Handling side effects

https://github.com/ericmasiello/tree-shaking-talk/tree/master/example07-handling-side-effects

• Webpack can be told to ignore potential side effects by setting the flag "sideEffects" to false in the library's package.json

What we learned