Problem
@prover-coder-ai/openapi-effect@1.0.22 is hard to consume from another strict TypeScript workspace because the package exports TypeScript source files as its public types:
"exports": {
".": {
"types": "./src/index.ts",
"import": "./dist/index.js"
}
}
When docker-git tried to replace openapi-fetch with @prover-coder-ai/openapi-effect, consumer tsc --noEmit resolved the package type surface through src/index.ts and then pulled in internal source modules that are not valid for external consumers.
Observed failures included:
src/generated/dispatch.ts: Cannot find module '../../tests/fixtures/petstore.openapi.js'
src/generated/dispatchers-by-path.ts: Cannot find module '../../tests/fixtures/petstore.openapi.js'
src/shell/api-client/create-client-runtime-helpers.ts: Cannot find name 'process'
The published source type graph also imports openapi-typescript-helpers, but the package metadata does not declare it as a dependency. That means consumers can fail unless they happen to install the helper package themselves.
Repro
In a strict external workspace:
import { createClientEffect } from "@prover-coder-ai/openapi-effect"
type paths = {
"/health": {
get: {
responses: {
200: {
content: {
"application/json": { ok: boolean }
}
}
}
}
}
}
const client = createClientEffect<paths>()
client.GET("/health")
Run:
Expected
External consumers should be able to import the public API without local paths shims or ambient module declarations.
Suggested fix
- Emit declaration files during package build.
- Change package exports from
./src/index.ts to generated ./dist/index.d.ts or equivalent public declaration output.
- Ensure published declaration files do not reference test fixtures or generated sample dispatchers.
- Declare
openapi-typescript-helpers if it is part of the public type surface, or avoid leaking it to consumers.
- Add a consumer fixture/test that installs the packed package into a separate strict TypeScript project and runs
tsc --noEmit.
Downstream impact
docker-git PR ProverCoderAI/docker-git#431 currently needs a local packages/openapi/src/types/openapi-effect.d.ts facade only because the published package type surface is not consumable directly. Once this is fixed upstream, that local facade and the related tsconfig paths mapping should be removed from docker-git.
Proof obligation
A fix is complete when a fresh consumer workspace can install @prover-coder-ai/openapi-effect, import createClientEffect, and pass tsc --noEmit without any local module declaration override.
Problem
@prover-coder-ai/openapi-effect@1.0.22is hard to consume from another strict TypeScript workspace because the package exports TypeScript source files as its public types:When
docker-gittried to replaceopenapi-fetchwith@prover-coder-ai/openapi-effect, consumertsc --noEmitresolved the package type surface throughsrc/index.tsand then pulled in internal source modules that are not valid for external consumers.Observed failures included:
The published source type graph also imports
openapi-typescript-helpers, but the package metadata does not declare it as a dependency. That means consumers can fail unless they happen to install the helper package themselves.Repro
In a strict external workspace:
Run:
Expected
External consumers should be able to import the public API without local
pathsshims or ambient module declarations.Suggested fix
./src/index.tsto generated./dist/index.d.tsor equivalent public declaration output.openapi-typescript-helpersif it is part of the public type surface, or avoid leaking it to consumers.tsc --noEmit.Downstream impact
docker-gitPR ProverCoderAI/docker-git#431 currently needs a localpackages/openapi/src/types/openapi-effect.d.tsfacade only because the published package type surface is not consumable directly. Once this is fixed upstream, that local facade and the relatedtsconfig pathsmapping should be removed fromdocker-git.Proof obligation
A fix is complete when a fresh consumer workspace can install
@prover-coder-ai/openapi-effect, importcreateClientEffect, and passtsc --noEmitwithout any local module declaration override.