How We Built a Design System (3) - Tree Shaking and Legacy Browser Support

External libraries like YDS v2 have a direct impact on service bundle size and browser compatibility. To solve this, Yogiyo's FE team tackled Tree Shaking optimization and legacy browser support as separate tasks.

For Tree Shaking to work properly, simply relying on Next.js is not enough. The library must be distributed as ESM, and sideEffects in package.json must be explicitly declared so the bundler can safely remove unused code.

The key here is maintaining module boundaries. If all code is bundled into a single file, or if the structure relies on barrel files and complex re-export patterns, the service bundler performs static analysis conservatively and may end up including unnecessary code.

To reduce this, the library build either maintains the original module structure via preserveModules: true, or specifies public entry points using the Multi-entry approach. External dependencies are also separated out via external, designed so that library and third-party code are not mixed into one file.

This structure also carries over to service-side optimization. When combined with Subpath Exports, only the needed modules can be imported directly, and by leveraging Next.js's experimental optimizePackageImports feature, you can get an effect close to direct import while still keeping barrel imports.

Experimental results support this. In a default Next.js environment, after installing yds2-react and using only a single SingleBadge, the main page's First Load JS and Total Size (as measured by Next Bundle Analyzer) dropped significantly, reducing the occupied size from around 1.58 MB down to 29 kB.

For legacy browser support, the starting point is distinguishing between Compile, Transpile, and Polyfill. Syntax conversion is Transpile, while supplementing features not available in the runtime environment is Polyfill, and Next.js's built-in polyfills alone cannot resolve all browser differences.

In particular, since Next.js's default polyfills are loaded mainly targeting below Chrome 64 or only cover a limited scope, APIs supported only in more recent browsers, such as Promise.allSettled(), can fall into blind spots. So instead of embedding polyfills in the library itself, the team chose an approach where the service application takes responsibility according to its own target browsers.

To implement this strategy, you need to clearly set target browsers using browserslist, and transpile even external libraries when necessary. Ultimately, the key isn't a single setting, but designing ESM distribution, sideEffects, external separation, maintaining module structure, and target-browser-based transpile/polyfill all together.