Reduce Bundle Size

Reduce Bundle Size

A disciplined workflow for shrinking a JavaScript/TypeScript library bundle. The core move is measure every change, revert anything that regresses, and stay within readability guardrails — not "shorten the code."

The measure-first loop

Do this for every change, no exceptions:

1. Baseline. Run the production build and record dist/index.js size (raw + gzip). For bunup/tsup, the output includes both. Write it down.
2. Make one focused change. A single dedup, a single extraction, a single dep removal.
3. Run CI. bun run ci (or equivalent npm test && npm run build). Tests must stay green. If any test fails, fix the test (if the behavior truly changed) or fix the refactor (if the test caught a regression) — never weaken the assertion.
4. Compare. New size vs baseline. Both raw and gzip. Gzip is the truth consumers experience; raw matters for budget claims.
5. Keep or revert. If the delta is meaningful (≥0.5 KB raw or clear structural win), keep it. If it's a wash AND hurts readability, revert.

Anti-habit to avoid: batching 10 changes then running CI once. You lose signal on which change caused the regression, and you can't cherry-pick.

Check the bundle's starting assumptions first

Before hunting for wins, verify the mental model:

• Are deps inlined or externalized? head -c 500 dist/index.js. If you see import { X } from "some-dep" at the top, deps are externalized and the bundle is mostly your own source code. Removing a dep won't shrink the bundle much — but it saves install footprint. If deps are inlined, dep removal is a bigger lever.
• Does the bundler report unused deps? Most modern bundlers do (bunup's unused() plugin, etc.). A reported unused dep may be a false positive (type-only import that still has runtime co-entry) — grep the source for actual runtime usage before removing.
• Does sideEffects: false apply? If the whole build is one minified file, consumer tree-shaking can't re-split it. Multi-entry bundling (when you're OK with the API impact) enables downstream tree-shaking.

Opportunities to look for (ranked by typical payoff)

Scan in roughly this order. Each subsection lists the shape of the opportunity and what the cleanup looks like.

1. Unused deps and dead files (biggest easy wins)

• Bundler's unused-dep report → grep for each in src/. If truly unused, bun remove <dep>.
• Components imported only by demo/example code that isn't part of the public entry → those UI components can be deleted along with the demo if the demo is also non-shipping. Confirm by following the import graph from src/index.ts.
• Dead export statements (re-exports nobody consumes) → remove from the top-level entry.
• An entire heavyweight dep whose only user is one internal component → consider replacing with a lightweight internal implementation. react-day-picker (30-50 KB) replaced with ~100 lines of dayjs-based month grid is a typical win.

2. Duplicated identical JSX blocks (high dedup value)

When three near-identical <Button> (or any element) blocks differ only in onClick/label/key/some prop:

• Extract an array of { id, label, ...vars } objects, map over it, render one element with vars interpolated.
• Prefer module-level const arrays over in-render literals when the data doesn't depend on props/state.
• If the data DOES depend on props/state (e.g. derived from isEdit), declare the array inside the component right before the return.
• If you need different extras per item (e.g. option A has a child Input, option B has a child DatePicker), keep the per-item conditional block inline — don't force uniformity.

3. Duplicated JSX structures → local component

When multiple form fields have identical wrapper/Label/Input markup (title/description/location fields in a form, for example), extract a local component inside the file:

const TextField = ({ name, placeholder, required = false }: {...}) => (
  <div className="grid gap-1 sm:gap-2">
    <Label htmlFor={name}>{t(name)}</Label>
    <Input id={name} name={name} value={formValues[name]} ... />
  </div>
)

Local-to-the-file first. Promote to a shared component only when 2+ files show the same shape.

4. Shared components across features → extract up

When two feature folders (e.g. day-view/ and week-view/) render near-identical sub-structures, extract to a shared module one level up. Example: a TimeHeaderRow that both a day view and a week view render with small style/timing differences. Parameterize only the things that actually differ (view name, animation timing), bake the rest into the component.

Watch for: if the shared component's props balloon (8+ visual knobs for two callers), the abstraction is leaking. Better to keep two 20-line variants than one 60-line abstract "configurable" variant.

5. Duplicated utility functions → hoist to a shared hook/util

The sniff test: the same 5-10 line function appears in 2+ files with identical logic. Example:

• const effectiveBusinessHours = useMemo(() => resourceId && getResourceById(resourceId)?.businessHours || fallback, ...) appearing in both grid-cell.tsx and event-form.tsx → extract to useEffectiveBusinessHours(resourceId).
• A toHiddenDaysSet(days?: WeekDays[]) helper duplicated in both library entry components → hoist to lib/utils.

6. Duplicated algorithm steps within one function → named helpers

Long algorithmic functions (positioning code, layout code) often have 2-3 near-identical inner loops. Extract each step as a locally-declared closure:

const findAvailableRow = (startCol, endCol) => { ... }
const place = (row, startCol, endCol, event, ...flags) => { ... }

Then the main logic becomes a short sequence of place(findAvailableRow(...), ...) calls. Big line savings, usually small bundle savings (minifiers handle token-level duplication), but maintenance wins compound.

7. Context providers that re-list every engine field

When contextValue = useMemo(() => ({ field1: engine.field1, field2: engine.field2, ...23 more }), [...]), replace with ...engine spread:

const contextValue = useMemo(() => ({ ...engine, override1: handler1, ...extras }), [engine, ...])

Saves 15-25 lines per provider, no behavior change.

8. Repeated reset/initial state literals → module constants

If { isOpen: false, event: null, updates: null } appears as both initial state AND 3 reset points, lift to const CLOSED_DIALOG = { isOpen: false, event: null, updates: null } as const. Small win but cleaner.