The validator, the badge endpoint, check-feeds.mjs (spec repo PR #43) and register-adopter.mjs (spec repo PR #46) all used to hardcode the newest schemas, so a feed on an earlier — but supported — release came back as broken with a single error about specVersion. All four are fixed. The same bug is still present in the packages that consume a feed.
Where
@opentechevents/validate now has two APIs, and the difference is the whole point:
validateDocument(json, { kind }) — async, checks against the version the document declares. For documents somebody else published.validateFeed / validateEvent — sync, always the latest published version. For documents this kit is writing.
These still call the second one on input they did not write:
packages/export-ics/src/cli.tspackages/export-jsonld/src/cli.tspackages/export-rss/src/cli.tspackages/build-feed (--check, worth a look: it assembles a feed from events/*.json in a fork, so "latest" may well be the right answer there)apps/publish/src/main.ts
Effect: ote-export-ics on a valid 0.3.0 feed refuses to convert it, with the message that the feed is invalid. It is not.
What to do
Per call site, decide which of the two questions is being asked, rather than swapping the import everywhere:
- Converting a feed somebody published (the exporters,
apps/publish) → validateDocument, and honour the support window: inside it the feed is valid and converts; outside it, the migration error.
- Checking a document this kit is producing (
build-feed --check over a fork's own events/*.json) → the current behaviour is probably right, since what those files should be written against is the current release. Worth stating in the code rather than leaving as the default that happens to be there.
Both CLIs are sync today, so this means making them async — small, but it is the reason it was left out of the validator work rather than folded into it.
Watch out for
- A version outside the support window is an error; being behind is not. The exporters must not degrade a verdict for a legitimate choice — see
packages/validate/src/versions.ts.
- Versions before 0.3.0 have no recommended profile (
recommendedProfileChecked: false). Absent is not "everything met".
- Each version loads on demand and is cached, so an exporter that meets several versions in one run pays for each once.
Context: this fell out of the validator work (multi-version validation, version notices, URL reachability). Scoped out there on purpose — it is the same bug, in packages that were not part of that change.
The validator, the badge endpoint,
check-feeds.mjs(spec repo PR #43) andregister-adopter.mjs(spec repo PR #46) all used to hardcode the newest schemas, so a feed on an earlier — but supported — release came back as broken with a single error aboutspecVersion. All four are fixed. The same bug is still present in the packages that consume a feed.Where
@opentechevents/validatenow has two APIs, and the difference is the whole point:validateDocument(json, { kind })— async, checks against the version the document declares. For documents somebody else published.validateFeed/validateEvent— sync, always the latest published version. For documents this kit is writing.These still call the second one on input they did not write:
packages/export-ics/src/cli.tspackages/export-jsonld/src/cli.tspackages/export-rss/src/cli.tspackages/build-feed(--check, worth a look: it assembles a feed fromevents/*.jsonin a fork, so "latest" may well be the right answer there)apps/publish/src/main.tsEffect:
ote-export-icson a valid 0.3.0 feed refuses to convert it, with the message that the feed is invalid. It is not.What to do
Per call site, decide which of the two questions is being asked, rather than swapping the import everywhere:
apps/publish) →validateDocument, and honour the support window: inside it the feed is valid and converts; outside it, the migration error.build-feed --checkover a fork's ownevents/*.json) → the current behaviour is probably right, since what those files should be written against is the current release. Worth stating in the code rather than leaving as the default that happens to be there.Both CLIs are sync today, so this means making them async — small, but it is the reason it was left out of the validator work rather than folded into it.
Watch out for
packages/validate/src/versions.ts.recommendedProfileChecked: false). Absent is not "everything met".Context: this fell out of the validator work (multi-version validation, version notices, URL reachability). Scoped out there on purpose — it is the same bug, in packages that were not part of that change.