Toss Bank Switches Internal Package Management to ESM-Only

Toss Bank's Tech Group announced a shift in internal package management from Dual package (supporting both ESM/CJS) to ESM-only. The previous approach involved the complexity of managing builds and type linking for both formats, along with the risk of Dual package hazard.

Problems with Dual Packages

Packages built separately for ESM and CJS may load different implementations depending on the module system. This can lead to separated shared states, such as React contexts or internal module caches, causing errors where Hooks fail to find values even when wrapped in a Provider. Additionally, type file linking paths may vary based on TypeScript configuration, risking reduced type safety where types are not found and treated as any.

Background of the ESM-Only Transition

In the past, Node.js could not load ESM via CJS require(). However, the situation changed with Node.js 22.12.0, which supports require(esm) without a separate flag. Toss Bank was able to identify usage and adjust support environments within the predictable context of internal packages. By adopting ESM, the standard JavaScript module system, they secured the benefits of tree shaking and simplified management.

Transition Effects and Future Plans

The switch to ESM-only relieved developers from the burden of simultaneously managing code and types for two implementations, while also reducing debugging complexity related to tracking loaded implementations for users. Toss Bank has standardized package development guidelines, including this transition, and plans to introduce details on type and source code provision methods and build configurations in the next post.