What happens
createTsProgram asserts on every semantic diagnostic in the program (src/shared/ts-utils.ts), and DEFAULT_TSCONFIG is ./tsconfig.json — for most projects, the config that includes the whole app. So an unrelated type error anywhere stops bridge generation.
Reproduced against the published 1.0.0 in a clean consumer:
// unrelated.ts — nothing to do with IPC
export const totallyUnrelated: string = 42;
RESULT: generation FAILED -> TypeScript failed with 1 error(s):
unrelated.ts(2,14): error TS2322: Type 'number' is not assignable to type 'string'.
Deleting that one file makes generation succeed. Nothing else changed.
Why it matters
The Rollup plugin regenerates on every buildStart. Mid-refactor — a half-written component, an import not yet added — the build fails with an error from the bridge generator, pointing at a file the generator has no interest in. In --watch, that is the normal state of a working session.
A scoped tsconfig avoids it, and example/ already uses tsconfig.ipc.json. But it is a convention the default does not enforce and the docs do not flag as load-bearing.
Suggested fix
Not "stop type-checking": the analyzer serializes types straight from the checker, so an error inside an IPC file's transitive imports can silently produce a wrong bridge. That has to keep aborting.
Scope the assertion to the analyzed *.ipc.ts files plus their transitive dependencies, and ignore diagnostics elsewhere. program.getSemanticDiagnostics(sourceFile) accepts a file, so this is a filter over the files the analyzer already resolves.
Worth pairing with a clearer message when an error is in scope, naming which IPC file pulled the broken import in.
Semver
Patch. It only makes generation succeed where it previously failed; no one depends on the failure.
What happens
createTsProgramasserts on every semantic diagnostic in the program (src/shared/ts-utils.ts), andDEFAULT_TSCONFIGis./tsconfig.json— for most projects, the config that includes the whole app. So an unrelated type error anywhere stops bridge generation.Reproduced against the published
1.0.0in a clean consumer:Deleting that one file makes generation succeed. Nothing else changed.
Why it matters
The Rollup plugin regenerates on every
buildStart. Mid-refactor — a half-written component, an import not yet added — the build fails with an error from the bridge generator, pointing at a file the generator has no interest in. In--watch, that is the normal state of a working session.A scoped tsconfig avoids it, and
example/already usestsconfig.ipc.json. But it is a convention the default does not enforce and the docs do not flag as load-bearing.Suggested fix
Not "stop type-checking": the analyzer serializes types straight from the checker, so an error inside an IPC file's transitive imports can silently produce a wrong bridge. That has to keep aborting.
Scope the assertion to the analyzed
*.ipc.tsfiles plus their transitive dependencies, and ignore diagnostics elsewhere.program.getSemanticDiagnostics(sourceFile)accepts a file, so this is a filter over the files the analyzer already resolves.Worth pairing with a clearer message when an error is in scope, naming which IPC file pulled the broken import in.
Semver
Patch. It only makes generation succeed where it previously failed; no one depends on the failure.