feat: CJS dual-publish
Labels: enhancement, roadmap
Summary
Publish both ESM and CommonJS builds to support older Node.js projects that haven't migrated to ESM yet.
Problem
throtto is ESM-only ("type": "module"). Projects using require() can't import it without dynamic import() workarounds. This excludes:
- Older Express/Fastify apps
- Some test frameworks with CJS-only configs
- Enterprise codebases locked to CJS
- AWS Lambda with older Node.js runtimes
Proposed solution
Use tsup dual output:
// tsup.config.ts
export default defineConfig({
format: ['esm', 'cjs'],
// ...
})
Update package.json exports with conditional exports:
{
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.js",
"require": "./dist/index.cjs"
}
}
}
Considerations
- Increases package size (~2x dist)
- Need to test CJS output doesn't break tree-shaking for ESM consumers
.d.cts type files may be needed
- All 40+ entry points need dual exports
Alternative: document ESM-only stance
If dual-publish is too much maintenance, clearly document:
- How to use throtto in CJS projects via dynamic
import()
- Minimum Node.js version for native ESM support
- Link to migration guides
Acceptance criteria
feat: CJS dual-publish
Labels:
enhancement,roadmapSummary
Publish both ESM and CommonJS builds to support older Node.js projects that haven't migrated to ESM yet.
Problem
throtto is ESM-only (
"type": "module"). Projects usingrequire()can't import it without dynamicimport()workarounds. This excludes:Proposed solution
Use
tsupdual output:Update
package.jsonexports with conditional exports:{ "exports": { ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js", "require": "./dist/index.cjs" } } }Considerations
.d.ctstype files may be neededAlternative: document ESM-only stance
If dual-publish is too much maintenance, clearly document:
import()Acceptance criteria