modularize

Split large test suites by behavior or topic into separate files named after the feature under test, such as coercion.test.ts or options.test.ts. Extract shared setup like beforeEach hooks into a helper file only when duplication is significant, then run each new test file individually.

Use roughly 200 lines as a warning signal, then evaluate logical cohesion, function sizes, and nesting complexity. Refactor when the file contains independent blocks; skip it if the file is a configuration dictionary, constants list, or single switch statement that belongs together.

Preserve the public contract by keeping the original exports and using a barrel file such as index.ts to re-export the split sub-modules. Consumers continue importing from the same path while the internals are reorganized into discrete modules.

Avoid splitting when the file is predominantly a configuration dictionary, list of constants, or one massive switch statement that logically belongs together. Also avoid speculative abstractions before multiple active callers exist, since over-splitting cohesive units causes jump-to-definition fatigue.

Run the targeted tests for the affected files first, then execute typechecking, the package build step to confirm ESM/CJS module resolution, and linting and formatting checks. Check compilation at each incremental extraction step rather than only at the end.