@cosyte/tsup-config
One dual-format build baseline, so every Cosyte library packs the same way.
Shared tsup build config (dual ESM + CJS, ES2023) for @cosyte/* libraries.
Why this exists
Dual-format publishing is where a library quietly breaks: the ESM build resolves, the CJS build does
not, the .d.ts files point at the wrong one, and nobody finds out until a consumer on the other
module system installs it. Getting that right once and copying the config into ten repositories means
getting it wrong in nine of them eventually.
The nearest alternative is a hand-written tsup.config.ts per repository. This is the same baseline
as a published package instead, so a fix to the out-extension or the target reaches every library
that uses it as a version bump.
Status
@cosyte/tsup-config is on the Cosyte 0.1.x line: the public API is settled and bump types follow ordinary semver.
Still moving: the compile target and the treeshake and splitting settings, all three of which change
what a consumer's published artifact looks like. The cosyteTsup(options) shape itself is the part
least likely to move.
Install
pnpm add -D @cosyte/tsup-config tsup
tsup (8 or 9) is a peer dependency. Node >=22.14; tsup 9 itself needs 22.18 or later. ESM
only.
Usage
tsup.config.ts is one call, and entry is the one option every consumer supplies, because only
the package knows what it builds:
import { cosyteTsup } from "@cosyte/tsup-config";
const config = cosyteTsup({ entry: ["src/index.ts"] });
config.format; // => ["esm", "cjs"]
config.outExtension({ format: "esm" }); // => { js: ".mjs" }
Export that object as the file's default (export default cosyteTsup({ entry: ["src/index.ts"] }))
and everything else is the enforced standard.
Pair it with @arethetypeswrong/cli (attw) as a publish gate. A dual build that emits the wrong
declaration for one of its two module systems still packs and still publishes; attw is what turns
that into a red before it reaches npm.
Entry points
| entry point | what it is |
|---|---|
@cosyte/tsup-config | the cosyteTsup(overrides?) factory, returning a tsup config object |
One entry point, so @cosyte/tsup-config is the only specifier a consumer ever writes.
Overrides
Anything in tsup's own Options can be passed to cosyteTsup and is merged over the baseline, so
adding a second entry point or switching a format off is one argument:
export default cosyteTsup({
entry: ["src/index.ts", "src/perf/index.ts"],
sourcemap: false,
});
The merge is shallow and the overrides win, so nothing here is unreachable. That is deliberate: a build config that cannot be adjusted per package is one a package works around by not using it. The baseline is what you get for free, not what you are held to.
PHI and safety
This package is build configuration. It shapes how a library is compiled and packed, reads no runtime input, and never sees patient data: nothing here logs, retains or transmits anything.
Compatibility
Dual ESM + CJS with .d.ts, ES2023 target, Node platform, treeshake on, splitting off,
.mjs and .cjs out-extensions, and sourcemaps. The out-extensions are deliberate: they make each
artifact's module system explicit in its filename rather than dependent on the nearest
package.json type field.
Contributing
Questions, bug reports and proposals go to the issue tracker. Pull requests are welcome, in cosyte/config, where this package lives.
A change has to clear the required verify job, and a change to the baseline needs a changeset
saying what moved: it changes the artifact every consumer publishes.
License
MIT, copyright Cosyte LLC. See LICENSE.