What this is
Two free, well-established tools that catch a class of TypeScript packaging bugs that unit tests never catch — silent ESM/CJS module resolution breakage. The industry standard (Azure SDK for JS, and recommended explicitly in publint's own docs) is to run both together.
- attw — detects type-masquerading issues like
FalseExportDefault (types declare a default export that doesn't match the runtime CJS export) and CJSOnlyExportsDefault. These cause silent breakage for consumers in mixed ESM/CJS projects.
- publint — validates the
exports map in package.json, catching mismatches between what the package advertises and what actually ships.
publint's docs explicitly say: "attw is able to report issues that publint does not, so it's recommended to use both tooling together."
Why it matters for b2-sdk-typescript
The SDK ships 9 subpath exports across dual ESM + CJS formats with .d.cts mirrors. That's exactly the configuration where these tools catch real bugs — bugs that only surface for consumers in specific environments (e.g., a Next.js project consuming the CJS build, or a Bun project consuming the ESM build) and that are very hard to diagnose without these gates.
At v0.1.0 pre-1.0, catching these now costs nothing. After 1.0 with external consumers depending on the type shapes, fixing them requires a semver major.
Industry reference
This is an adversarially-verified finding (not marketing) — Azure SDK for JS uses this pattern as a release gate. It's the clearest reference implementation for TypeScript cloud storage SDKs.
Suggested implementation
pnpm add -D @arethetypeswrong/cli publint
Add to package.json scripts:
"check:types": "attw --pack . && publint"
Add to ci.yml (after build step, before publish):
- name: Check type exports
run: pnpm check:types
Do you think this is worth fixing?
Happy to hear your take — if there's a reason the current build/verify scripts already cover this, or if you've already tried these tools and hit issues, would be good to know. The ask from our side is just to have this gated before the 1.0 release so external consumers don't hit silent breakage.
/cc @sophiecarreras
What this is
Two free, well-established tools that catch a class of TypeScript packaging bugs that unit tests never catch — silent ESM/CJS module resolution breakage. The industry standard (Azure SDK for JS, and recommended explicitly in publint's own docs) is to run both together.
FalseExportDefault(types declare a default export that doesn't match the runtime CJS export) andCJSOnlyExportsDefault. These cause silent breakage for consumers in mixed ESM/CJS projects.exportsmap inpackage.json, catching mismatches between what the package advertises and what actually ships.publint's docs explicitly say: "attw is able to report issues that publint does not, so it's recommended to use both tooling together."
Why it matters for
b2-sdk-typescriptThe SDK ships 9 subpath exports across dual ESM + CJS formats with
.d.ctsmirrors. That's exactly the configuration where these tools catch real bugs — bugs that only surface for consumers in specific environments (e.g., a Next.js project consuming the CJS build, or a Bun project consuming the ESM build) and that are very hard to diagnose without these gates.At
v0.1.0pre-1.0, catching these now costs nothing. After 1.0 with external consumers depending on the type shapes, fixing them requires a semver major.Industry reference
This is an adversarially-verified finding (not marketing) — Azure SDK for JS uses this pattern as a release gate. It's the clearest reference implementation for TypeScript cloud storage SDKs.
Suggested implementation
Add to
package.jsonscripts:Add to
ci.yml(after build step, before publish):Do you think this is worth fixing?
Happy to hear your take — if there's a reason the current build/verify scripts already cover this, or if you've already tried these tools and hit issues, would be good to know. The ask from our side is just to have this gated before the 1.0 release so external consumers don't hit silent breakage.
/cc @sophiecarreras