fix(packaging): resolve correct .d.cts types for CJS consumers#846
Closed
david-illing-ck wants to merge 4 commits into
Closed
fix(packaging): resolve correct .d.cts types for CJS consumers#846david-illing-ck wants to merge 4 commits into
david-illing-ck wants to merge 4 commits into
Conversation
|
@david-illing-ck is attempting to deploy a commit to the langfuse Team on Vercel. A member of the Team first needs to authorize it. |
Each package shipped a single top-level "types" in its exports map pointing at the ESM `.d.ts`. Because every package is `"type": "module"`, TypeScript's node16/nodenext resolution interprets that declaration as ESM, so CommonJS consumers (moduleResolution node16/nodenext) cannot import the packages: - TS1479 on value imports - TS1541 on type-only imports The matching `.d.cts` declarations are already emitted by tsup but were never referenced. Nest the `types` condition under each `import`/`require` branch so CJS consumers resolve `.d.cts` and ESM consumers resolve `.d.ts`. This is purely additive to type resolution — runtime entries and ESM consumers are unchanged. Verified with @arethetypeswrong/cli (all green across node10, node16 from CJS and ESM, and bundler) and against a real CommonJS + node16 consumer build. Fixes langfuse#748 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
david-illing-ck
force-pushed
the
fix/cjs-types-dual-package-exports
branch
from
June 22, 2026 20:53
22e67fa to
e3bb635
Compare
david-illing-ck
marked this pull request as ready for review
June 22, 2026 21:06
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Fixes #748.
Importing any
@langfuse/*package from a CommonJS project using TypeScriptmoduleResolution: node16/nodenextfails to type-check. Each package ships a single top-leveltypesin itsexportsmap pointing at the ESM.d.ts, and because every package is"type": "module", node16/nodenext resolution interprets that declaration as ESM. A CommonJS consumer therefore resolves an ESM declaration for arequire()and the compiler rejects it:TS1479on value importsTS1541on type-only importsThis blocks CJS consumers on modern module resolution even though a working
.cjsruntime build already ships.Changes
The matching
.d.ctsdeclarations are already emitted by tsup — they were just never referenced in theexportsmap. This PR nests thetypescondition under eachimport/requirebranch so CJS consumers resolve.d.ctsand ESM consumers resolve.d.ts:Applied identically to all 7 packages:
core,client,tracing,otel,openai,langchain, andbrowser.This is purely additive to type resolution — ESM consumers still resolve
import.types → .d.tsbyte-for-byte, runtimedefaultentries are unchanged, andnode/classic-resolution and bundler consumers are unaffected. No build config changes (the.d.ctsartifacts already exist).Verification
@arethetypeswrong/cli— "No problems found" for every package acrossnode10,node16 (from CJS),node16 (from ESM), andbundler(previously failednode16 (from CJS)).moduleResolution: node16project went from failing to a cleantscwith no consumer-side source changes.It apears I'm missing credentials to run to some of the tests, but I've run what I can without them.
pnpm lintpnpm typecheckpnpm testpnpm test:integrationpnpm test:e2epnpm format:checkRelease info
Bump level
Libraries affected
Greptile Summary
This PR fixes TypeScript
TS1479/TS1541errors for CommonJS consumers usingmoduleResolution: node16ornodenextby restructuring theexportsfield in all 7package.jsonfiles. Previously, a single top-leveltypescondition pointed only at the ESM.d.tsdeclaration; CJS consumers resolved that ESM declaration for arequire()call, which modern TypeScript rejects.exportsmap is restructured sorequire.typesresolves.d.ctsandimport.typesresolves.d.ts, using the runtime files already emitted by tsup (dts: truewith a CJS.cjsextension produces.d.ctsautomatically).defaultentries point to the same.mjs/.cjsartifacts as before; the top-level"types"fallback for pre-exportstooling is preserved.Confidence Score: 5/5
Safe to merge — changes are confined to exports metadata in package manifests with no modifications to build config or source code.
All 7 packages receive an identical, mechanical change that adds nested types resolution under each import/require branch. The .d.cts artifacts were already being emitted by tsup; this PR simply wires the exports map to reference them. Runtime entries (default) are byte-for-byte unchanged, the top-level types fallback is preserved, and the PR author verified correctness with @arethetypeswrong/cli across all four resolution modes.
No files require special attention — all changes are structurally identical across the 7 package manifests.
Flowchart
%%{init: {'theme': 'neutral'}}%% flowchart TD Consumer([TypeScript Consumer]) Consumer -->|ESM / import| ImportBranch["exports.import"] Consumer -->|CJS / require| RequireBranch["exports.require"] ImportBranch --> ImportTypes["types: ./dist/index.d.ts"] ImportBranch --> ImportDefault["default: ./dist/index.mjs"] RequireBranch --> RequireTypes["types: ./dist/index.d.cts"] RequireBranch --> RequireDefault["default: ./dist/index.cjs"] ImportTypes --> ESMDecl["ESM declaration (.d.ts)"] RequireTypes --> CJSDecl["CJS declaration (.d.cts) new"] ImportDefault --> ESMRuntime[".mjs runtime"] RequireDefault --> CJSRuntime[".cjs runtime"] style CJSDecl fill:#22c55e,color:#fff style RequireTypes fill:#22c55e,color:#fff%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD Consumer([TypeScript Consumer]) Consumer -->|ESM / import| ImportBranch["exports.import"] Consumer -->|CJS / require| RequireBranch["exports.require"] ImportBranch --> ImportTypes["types: ./dist/index.d.ts"] ImportBranch --> ImportDefault["default: ./dist/index.mjs"] RequireBranch --> RequireTypes["types: ./dist/index.d.cts"] RequireBranch --> RequireDefault["default: ./dist/index.cjs"] ImportTypes --> ESMDecl["ESM declaration (.d.ts)"] RequireTypes --> CJSDecl["CJS declaration (.d.cts) new"] ImportDefault --> ESMRuntime[".mjs runtime"] RequireDefault --> CJSRuntime[".cjs runtime"] style CJSDecl fill:#22c55e,color:#fff style RequireTypes fill:#22c55e,color:#fffReviews (1): Last reviewed commit: "fix(packaging): resolve correct .d.cts t..." | Re-trigger Greptile