fix: migrate to comark-content 0.4 single-source API - #36
Merged
Conversation
comark-content 0.4 gives each instance exactly one source and a name.
`sources: { … }` is no longer an option, so it was silently ignored and the
layer built an instance with no source: navigation returned `[]` and every
page 404'd, with no error anywhere.
- `sources: { content: … }` -> `source: …`, so the instance name is `default`
- `content.list(['content'])` -> `content.list()`
- `content.manifest.items` -> `(await content.manifest()).items`, the manifest
being an async producer rather than a live property
- annotate instances as `DocsContent` (`ComarkContent<…, 'default'>`): the
instance name is a type parameter reaching `get()`'s argument, so the bare
`ComarkContent` is not a supertype of a concrete instance
- update the contract test, which pins this exact surface
- point the comark-content dependency at the 0.4 preview build
Nothing reads the source name, so no cache keys or route shapes change.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
commit: |
`ComarkContent` is the unnarrowed shape: its instance-name parameter drives the conditional types behind `get()` and `list()`, so a concrete instance is not assignable to it and annotating with it widens (or fails). Deriving from the factory keeps every narrowing comark-content generates, and drops the type import entirely.
◈ PR Lens
Architecture 
6 components touched across 5 lanes. Data flow 
Drill down
|
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
2 participants
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.
Written by an AI agent on behalf of @atinux, who has reviewed it.
Why
comark-content 0.4 (comarkdown/comark-content#120) gives each instance exactly one source and a name.
sources: { … }is no longer an option.It is dropped silently rather than rejected, so the layer built an instance with no source at all:
/api/content/navigationreturned[]and every page 404'd, with no error in the logs. Running the comark-content docs site against the 0.4 branch is what surfaced it.What changed
sources: { content: … }source: …(instance name becomesdefault)content.list(['content'])content.list()content.manifest.items(await content.manifest()).itemsmanifestis now an async producer returning saveable data, not a live property.Nothing in the layer reads the source name — no
meta.sourcechecks, nocontent/…key literals — so cache namespaces, route shapes and the webhook payloads are unchanged.The type annotations
ComarkContent's instance name is a type parameter that reachesget()'s argument type, soComarkContent(name widened tostring) is not a supertype of a concrete instance: assigning one fails understrictFunctionTypes. The five annotations now use a localDocsContent = ComarkContent<Record<string, unknown>, 'default'>.That is a workaround for an upstream ergonomics problem, as far as I can tell — the obvious annotation cannot hold any real instance. Worth raising on the comark-content side; this PR does not depend on the outcome either way.
Dependency
comark-contentnow points at the 0.4 preview buildpkg.pr.new/comark-content@7da031b, since the API this PR targets is not released yet.Verification
All five CI steps were run locally against that build:
lint(0 errors, 4 pre-existing warnings),test(154 passed),dev:prepare,typecheck,build.test/content-contract.test.tsneeded updating — it is the file that pins this surface, and it caught both breaks. It now asserts againstsource:,await content.manifest(), and thedefault:index.mdcache key.Beyond CI: the comark-content docs site was served against this branch with the 0.4 build, and every page,
navigation,search-sectionsand/raw/**.mdanswered with no request errors. The layer's own playground was checked the same way in dev.The GitHub-source paths (production
getProdContent, previews, the revalidate webhook) were not exercised — they need a token and live commits.revalidate.post.tsis a two-line change to the manifest read, but it is the least covered part of this PR.