Interfaces

Migrating from 0.5.0

What changes in @meantjs/schema 0.6.0 and @meantjs/cli 0.5.0, prepared for the latest dist-tag and not yet published, for code written against @candid-core/schema 0.5.0 and @candid-core/cli 0.4.0: the same code under new package names, a CLI command named meant, and two new lines at the top of every generated module.

This page is for code written against @candid-core/schema 0.5.0 and @candid-core/cli 0.4.0, the pair under the npm latest dist-tag today, published on 2026-10-27. The repository is prepared as the next stable pair, under new names: @meantjs/schema 0.6.0 and @meantjs/cli 0.5.0, which npm does not hold yet. Every change is recorded under those two versions in the schema package's changelog and the CLI's changelog. Coming from an earlier pair, read Migrating from 0.4.0, Migrating from 0.3.0 and Migrating from 0.2.0 first.

The upgrade changes names, not code. The project ships under two names, ic-reactor for the Internet Computer and Meant, which is not tied to one chain; the compiler crate is meant already, and the pair takes the same name, in the @meantjs scope of the profile packages. @meantjs/schema 0.6.0 is @candid-core/schema 0.5.0's code under the new name: with comments removed, every file it ships is identical to 0.5.0's. @meantjs/cli 0.5.0 is @candid-core/cli 0.4.0 under the new name, with the command meant: its library exports the same names with the same declarations, and its commands take the same arguments and exit with the same codes. No wire byte, Contract, identity or envelope changes. What changes in the output is the first two lines of every generated module.

Names#

Replace @candid-core/schema with @meantjs/schema in every import of your own code, and @candid-core/cli with @meantjs/cli where you import the CLI's library. The subpaths keep their names: @meantjs/schema/validate, @meantjs/schema/contract and @meantjs/schema/codec. No exported name changes, and no signature does.

Do not mix the two packages in one program. Each declares its own brands, so a value typed by one is not always assignable to the other's type: a Principal from @candid-core/schema 0.5.0 passed where @meantjs/schema 0.6.0's Principal is expected fails with TS2322 (measured with TypeScript 7.0.2, strict). A generated module left on the old import therefore does not type-check against code written for the new one, which is the compiler pointing at the regeneration below. Uninstall @candid-core/schema and @candid-core/cli once nothing imports them.

The command#

The package installs one command, meant, where 0.4.0 installs candid-core-cli. Replace candid-core-cli with meant in your scripts: meant gen, meant project and meant check take the same arguments and flags as before, exit with the same codes, and print --json documents whose schemaVersion is still 1. Outside a script, run it as npx @meantjs/cli gen …, which always names this package. Never run a bare npx meant: the unscoped meant package on npm belongs to another author, so where this package is not installed, npx would offer to download and run that one.

meant is also the name of the Rust compiler's binary, whose commands are compile and validate. In a shell, a bare meant runs whichever comes first on the PATH; a package.json script puts this package's command first.

Generated modules#

Every module CLI 0.4.0 writes opens with these two lines:

// Generated by candid-core-ts from a candid-core Contract. Do not edit.
import * as $ from "@candid-core/schema";

and every module CLI 0.5.0 writes opens with these:

// Generated by Meant from a Meant Contract. Do not edit.
import * as $ from "@meantjs/schema";

A module's other lines are unchanged, and so is every envelope. But meant gen --check compares bytes, so it reports every module 0.4.0 wrote as drifted, exit 1, until meant gen runs again; the envelopes beside them it reports unchanged. Measured on the repository's tracked .did files, both releases compile the same 40 and refuse the same 4 with the same failure documents, the 40 envelopes are byte-identical, and each of the 40 modules differs from 0.4.0's in these two lines and in no other.

What keeps the old name#

The strings inside a Contract document are not package names, and this release changes none of them: the format candid-core, the canonical form candid-core-canon-1, the candid-core:contract:v1 and candid-core:interface:v1 identity domains, and the org.candid-core.field-names/v1 envelope extension. The two domains are hashed into every contract_id and interface_id, so renaming them would move every identity. schemaFromContract checks these strings exactly as 0.5.0 does, so a Contract or envelope that loaded before loads the same.

The five profile packages at 0.4.0 depend on the old pair: @meantjs/profile on @candid-core/cli 0.4.0, and @meantjs/consent on @candid-core/schema 0.5.0. Their declared types take no value of either pair, so your own code can move to the new names while the old pair stays installed as their dependency, until a release of theirs moves too.

Order of upgrade#

Move both packages in one step. The CLI peers its schema release exactly: @meantjs/cli 0.5.0 peers @meantjs/schema 0.6.0, as @candid-core/cli 0.4.0 peers @candid-core/schema 0.5.0. Because the names differ and both peers are optional, npm does not refuse a mixed install, so the order is yours to keep: install the new pair, replace candid-core-cli with meant in your scripts, run meant gen over every committed module, replace the old imports in your own code, run tsc, and uninstall the old pair. Once both are published, the plain npm install --save-exact @meantjs/schema and npm install --save-dev --save-exact @meantjs/cli select them from latest; until then npm holds no release under either name.

Edit this page on GitHub