The io-package.json check accepts the release-script's NEXT placeholder in common.news

[krobipd]

What happens

Since 6.2.2, tests.packageFiles() validates io-package.json against the js-controller schema. That schema allows only version numbers as keys of common.news, so every tree that carries the release-script's NEXT placeholder fails:

1) io-package.json matches its schema
   Error: io-package.json does not match the schema https://raw.githubusercontent.com/ioBroker/ioBroker.js-controller/master/schemas/io-package.json:
     - /common/news: must NOT have additional properties "NEXT"

(measured with 6.2.2 on a real adapter tree, see below)

Why the placeholder is legitimate

common.news.NEXT is where @alcalzone/release-script-plugin-iobroker collects the news of the next version while its number does not exist yet. On release, the plugin replaces the key with the version number (packages/plugin-iobroker/src/index.ts L150–162, covered by its test "preserves the NEXT news in io-package.json"). So the placeholder exists exactly between two releases — which is when npm test runs on every commit and pull request. It never reaches a published package, so the js-controller schema is right not to know it; the package test, however, runs on the development tree.

ignoreIoPackageValidation: true is not a good answer here, because it turns off the whole check for one placeholder.

The change

getIoPackageValidator() now adds the placeholder to the downloaded schema before compiling it — the same approach adaptSchemaForTab() already takes for the jsonConfig schema. ^NEXT$ is registered as a second patternProperties entry that points to the same #/definitions/multilingual definition as the version keys, so the placeholder's content stays validated (en required, only known languages, strings), error paths read /common/news/NEXT/..., and min/maxProperties keep counting it like the version it becomes. Nothing else changes; the document itself is not touched.

• src/tests/packageFiles/index.ts: NEWS_PLACEHOLDER, adaptSchemaForNewsPlaceholder(), one call in getIoPackageValidator()
• src/tests/packageFiles/index.test.ts: unit tests (schema rejects the placeholder before the adaptation, accepts it after, still validates its content, still rejects any other key)
• README.md, CHANGELOG.md, build/

Verification

• npm run check, npm run lint, npm run build, npm test (64 passing)
• Real adapter tree with common.news.NEXT (ioBroker.homeconnect before its 1.19.1 cut): test:package with 6.2.2 → 1 failing (the error above); with this branch → 73 passing. Counter-checks on the same tree with this branch: a typo language inside NEXT ("dx") → /common/news/NEXT: must NOT have additional properties "dx"; common.installedFrom → still rejected.

🤖 Generated with Claude Code

[mcm1957]

Not sure if we really should allow NEXT within the SCHEMA.

Maybe the releasescritp should be adapted. Or testing could detect LOCAL runs. NEXT must NOT be present within io.package committed to github at all as this would cause NEXT to propaget to builder and installations causein problems there.

AND if we really want to allow ist why not add it to the schema directly and hanle it at all relevant places?

Remember: The content of the io.package.json (incl. news) is loaded into the official repofiles and hence delivered to the user systems. So if theres a 'NEXT' this will arrive at user systems too and must be handled by admin etc.

So next at a local system test run is OK, but it should never be allowed at github in my oppinion.

[krobipd]

You are right — the placeholder must never sit in a committed io-package.json. We have changed our release tooling accordingly: the NEXT entry now lives outside the repository and is only injected into the working tree right before the release-script cut, so the schema check in 6.2.2 never sees it on GitHub or in CI. With that, this PR is no longer needed on our side and I'm closing it. Thanks for the feedback.