Lint and resolve
Two offline commands for a local tree. celigo lint validates the documents against the platform's published API schemas before you push; celigo resolve turns any reference — a link, a path, a type:id, an id — into the document's path. Neither needs a token or a profile.
celigo lint
Validate the tree's documents against the platform's published API schemas — the @celigo/api-specs package on npm, the same schemas behind the OpenAPI specs. The push guards that can be decided offline run too, with the same wording push --dry-run uses, so a clean lint is most of a clean plan.
Signature
celigo lint [refs...] [flags]Arguments
[refs...]
file path, type:id, or bare id
No
Narrow the check to these resources. Without refs, every tracked and new document is checked.
Flags
--dir <path>
string
.
Tree root directory.
--strict
boolean
false
Treat every warning as an error.
--specs <dir>
string
—
Pin a local schema pack directory (a schemas.json) instead of the cached or bundled schemas.
Output
One line per finding — severity, file, JSON pointer, message — then a summary and, on stderr, the schema pack that was used:
error exports/New Orders/export.json /http/relativeURI expected string, found number (push will create this)
warning connections/Shopify/connection.json /http/unencrypted/region 'region' is not a documented field here
already on this account: 3 clean connection documents carry /http/unencrypted/region
1 error, 1 warning across 212 documents.
specs: integrator-api-specs ae8d0a4 (2026-09-04, auto-updated 0.2.3)A clean tree prints Clean — N documents checked. The exit code is 1 when there is at least one error, and 0 otherwise.
What lint reports
Unknown field, type mismatch, enum miss
warning or error
A shape the schema does not describe. The account outranks the specs (below).
Masked credential placeholder on a create
error
A "******" in a new document would be sent as the credential.
The responseMapping object wrapper
error, always
fields or lists as an object at any step position, in flows, tools, and APIs. The platform accepts it and erases the step's mappings, so no evidence downgrades it and the schema pack is not consulted. A value that is neither object nor array is is not an array (found <type>).
invalid-json
error
A tracked file that is not a JSON object: unresolved git merge conflict (conflict markers at line N), invalid JSON: <position>, or not a JSON object. A pull-generated .link.json or .external.json that no longer parses is reported the same way.
conflict-markers
error
A script.js or instructions.md holding git conflict markers.
unresolved-reference
error
A path placeholder or @bindings/ key that names neither a tracked file, nor a new file in the tree, nor a bound id — one error per reference, at its pointer.
location
error
A new file whose folder push cannot honor: an untracked integration folder, an unknown flow or API group, an instances/ folder with no parent.
scope
error
In a tree pulled as one integration, a new file or edited document whose owner is another integration. Unedited borrowed dependencies are not reported.
The account outranks the specs. The published schemas are stricter than the API on real data, so a finding is downgraded to a warning when any server-identical document of the same type on this account already exhibits the shape — a field existing rebuts "unknown", the same JSON type rebuts a type mismatch, the exact value rebuts an enum miss. A create that introduces a shape nothing on the account backs is an error, because there is no evidence the platform accepts it. Spec-contradicted findings are appended to the per-machine .celigo/local/lint-feedback.jsonl — field paths and type classes only, never values — as feedback for the specs.
--strict is not yet a usable CI gate. A pristine pull of a real account produces warnings, so --strict fails everything until the published schemas catch up. Plain celigo lint (errors only) is the gate to run.
Where the schemas come from
Each release bundles the schema pack version it was built with. At most once every 24 hours — never in CI, and never failing or changing a command's outcome — the CLI checks npm for a newer @celigo/api-specs pack, verifies the tarball's integrity, and caches it under ~/.celigo/specs/<version>/ (the two newest versions are kept). Lint uses the newest valid pack it has, cached or bundled, and the provenance line names it: auto-updated <version>, bundled <version>, or pinned with --specs. A corrupt or missing cache degrades freshness, never correctness.
The check talks to registry.npmjs.org directly and does not consult an .npmrc mirror; on a mirror-only network the bundled pack keeps working. Opt out with CELIGO_NO_SPEC_UPDATE=1 for one environment, or celigo config set specs_auto_update false machine-wide. See Configuration reference.
Example
celigo resolve
Print the path of the real document behind any reference. Offline — it reads only .celigo/manifest.json (and, in a neutral tree, .celigo/bindings.json).
Signature
Arguments
<ref>
string
Yes
A link (a .link.json pointer or a symlink), any tree file path, type:id, a bare id, or — in a neutral tree — an @bindings/<key> key.
Flags
--dir <path>
string
.
Tree root directory.
--open
boolean
false
Open the resolved file with the VS Code code CLI.
A script resolves to its editable script.js; every other type resolves to its document file. --format json adds the type, the id, and the absolute target. In a neutral tree, celigo resolve @bindings/connection/shopify prints the id and name the key resolves to in this environment: 6a1b2c3d4e5f6a7b8c9d0e1f (Shopify).
Example
Related
Push changes — the same guards at plan time, plus the ones that need the account.
Neutral trees —
@bindings/keys and.celigo/bindings.json.Configuration reference —
specs_auto_updateandCELIGO_NO_SPEC_UPDATE.
Last updated
Was this helpful?