Skip to content

feat(jobnik-openapi): make the specification exist exactly once - #6

Open
CptSchnitz wants to merge 1 commit into
migration/03-pull-request-cifrom
migration/04-openapi-package
Open

feat(jobnik-openapi): make the specification exist exactly once#6
CptSchnitz wants to merge 1 commit into
migration/03-pull-request-cifrom
migration/04-openapi-package

Conversation

@CptSchnitz

Copy link
Copy Markdown
Collaborator

Introduce jobnik-openapi, a private unscoped workspace package that owns
the OpenAPI specification: the versioned source (openapi_v1.yaml), the
build that merges it into openapi3.yaml, the specification lint task, and
the generated request/response types (openapi.d.ts).

The manager takes it as a runtime dependency, imports request/response
types from it, and resolves the specification file through the module
system (openapiFilePath) instead of a copied asset. Its own generated
declaration and generation script are deleted.

The SDK takes it as a development-time dependency only, since the SDK is
published and this package is not. It keeps its own generation script,
which rewrites job/stage/task identifier schemas into branded types, and
continues to ship a copy of the specification in its build output because
it parses the specification at runtime.

A new generate:check turbo task reruns both the package's and the SDK's
generators and fails if the result differs from what is committed, wired
into the pull-request workflow as "Specification drift".

Regenerating the SDK's committed types against the current toolchain
incidentally fixed pre-existing comment-formatting drift unrelated to this
move.


Stack created with GitHub Stacks CLIGive Feedback 💬

Introduce jobnik-openapi, a private unscoped workspace package that owns
the OpenAPI specification: the versioned source (openapi_v1.yaml), the
build that merges it into openapi3.yaml, the specification lint task, and
the generated request/response types (openapi.d.ts).

The manager takes it as a runtime dependency, imports request/response
types from it, and resolves the specification file through the module
system (openapiFilePath) instead of a copied asset. Its own generated
declaration and generation script are deleted.

The SDK takes it as a development-time dependency only, since the SDK is
published and this package is not. It keeps its own generation script,
which rewrites job/stage/task identifier schemas into branded types, and
continues to ship a copy of the specification in its build output because
it parses the specification at runtime.

A new generate:check turbo task reruns both the package's and the SDK's
generators and fails if the result differs from what is committed, wired
into the pull-request workflow as "Specification drift".

Regenerating the SDK's committed types against the current toolchain
incidentally fixed pre-existing comment-formatting drift unrelated to this
move.
@github-actions

Copy link
Copy Markdown

Coverage Report for apps/jobnik-manager

Status Category Percentage Covered / Total
🟢 Lines 100% (🎯 80%) 767 / 767
🟢 Statements 100% (🎯 80%) 784 / 784
🟢 Functions 100% (🎯 80%) 112 / 112
🟢 Branches 100% (🎯 80%) 219 / 219
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
apps/jobnik-manager/src/serverBuilder.ts 100% 100% 100% 100%
apps/jobnik-manager/src/api/v1/jobs/controller.ts 100% 100% 100% 100%
apps/jobnik-manager/src/api/v1/stages/controller.ts 100% 100% 100% 100%
apps/jobnik-manager/src/api/v1/tasks/controller.ts 100% 100% 100% 100%
Generated in workflow #2 for commit 6f8b3d1 by the Vitest Coverage Report Action

@CptSchnitz
CptSchnitz marked this pull request as ready for review August 23, 2026 11:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant