A charting dependency your product relies on publishes only a CommonJS build and accounts for a large share of your main bundle. As the person making the call, how do you weigh working around it, forking it, replacing it, or simply accepting the bytes?

## Frame the decision before comparing options The instinct is to rank the technical options. The useful move first is to establish what the bytes are actually costing, because that number sets how much effort is justified and it varies by an order of magnitude between products. Three questions answer it: 1. **Who downloads it?** If the library is in the entry that every visitor loads, everyone pays. If only a subset of users reach the feature, the population that pays is smaller — and the first thing to check is whether the cost is falling on people who never see the feature. 2. **What does the delay translate to?** Bytes are not the metric anyone cares about; they are a proxy for time on a slow connection and time on the main thread parsing and executing. Connect the size to a user-visible effect on real devices, not to a number in a report. 3. **What is the counterfactual?** If removing this dependency saves 15% of a bundle that is already fine on your users' devices and networks, the whole exercise is discretionary. Measure your field data before you spend a quarter on it. A principal-level answer starts here. An answer that jumps straight to "fork it and publish ESM" has skipped the only step that decides whether any of this is worth doing. ## The ladder of options, by cost of ownership **Work around it in place.** Many CommonJS packages are still split into files, so importing the specific modules you use recovers a large share of the size with no change of dependency, no fork, and no migration. It is reversible, it can be enforced with a lint rule, and it is what you should try before anything else. It fails when the package really is one monolithic file, or when its internals cross-reference so heavily that the deep import pulls in most of the library anyway — which you find out in an hour. **Trim what you actually use.** Some charting and utility libraries ship a plugin or registry architecture where you register only the pieces you need. Where that exists, it is the intended path and costs nothing but discipline. **Push the fix upstream.** Opening an issue or a pull request that adds an ES-module build is the highest-leverage option when the maintainers are responsive: you pay once, everyone benefits, and you do not own the result. It is also the slowest and least certain, so it pairs well with a workaround shipped now. **Fork it.** This is the option teams consistently underprice. The visible cost is the week it takes to produce the build; the real cost is permanent: tracking upstream releases, re-applying your changes, owning security advisories against a package your dependency scanner no longer recognises, and explaining the fork to every future engineer. Take it only when the dependency is strategically important, upstream is unresponsive, and someone will own it by name. **Replace it.** Priced as a migration, not as a swap. Charting libraries in particular hide their cost in the long tail: the tooltip behaviour someone depends on, the export-to-image path, the accessibility work already done, the exact visual identity of the existing charts. Spike the two or three hardest charts against the candidate before committing, and count the test rewrite. **Accept it.** Perfectly defensible. What makes it a decision rather than a drift is writing it down: what the library costs, why the alternatives were rejected, what would cause you to revisit — a change in who reaches the feature, an ES-module build appearing upstream, the number crossing an agreed limit. ## What separates a strong answer Three things. First, sequencing by reversibility: try the cheap, undoable thing before the expensive, permanent one. Second, honest pricing of the fork — most candidates treat it as a one-week task and never mention the maintenance tail. Third, treating "accept it" as an available answer, because a leader who cannot say "this cost is fine" will spend the team's quarters on savings nobody feels. ## The policy behind the incident The last move is to stop this arriving as a surprise again. That means an adoption check on new dependencies — what does it publish, how big is it in your build, what does it depend on transitively — applied at the moment someone proposes it, when switching is free. The expensive version of this decision only exists because the cheap version was skipped a year earlier.