notcms package includes both the SDK and the notcms CLI. Use the
installed CLI with npx notcms (npm) or pnpm exec notcms (pnpm), so schema
creation and application imports use the same installed package version.
Upgrade an existing project
- Commit or back up your current config, generated schema and lockfile locally.
- Remove
notcms-kitif it is a direct project dependency, and upgradenotcms:
@latest selects the registry’s latest release. Teams that pin versions should
choose their supported target version explicitly instead. init deliberately
preserves existing dependency specs, including old prereleases; running it alone
does not upgrade notcms@0.0.12-development.
- Keep
notcms.config.jsonandNOTCMS_SECRET_KEY/NOTCMS_WORKSPACE_ID. Do not reruninitjust to migrate: refresh the existing schema instead.
- Replace scripts that call
notcms-kitwith the correspondingnotcmscommand.notcms-kit initbecomesnotcms init, andnotcms-kit pullbecomesnotcms pull. There is no separate CLI dependency to add. - Inspect the generated schema diff and typecheck/test your application.
Database/property keys are used exactly as generated: use bracket notation
for names with spaces. A public database ID may use the
nids_prefix; keep the generated ID instead of stripping its prefix or substituting a Notion page ID. The client still supportslist()andget(pageId). - Handle the SDK error tuple explicitly. A failed CMS request is not an empty result or a missing page:
New projects and CI
For a new project, usenpm install notcms then npx notcms init.
Connect and sync your databases in the dashboard before the first pull. init
handles config, browser login when needed, dependency setup, and the first pull.
Keep credentials on the server and out of version control.
For CI, install from the lockfile, inject credentials as secrets, and run:
pull locally and review/commit its
output to fix it.