[clauderic]

Stacked on #1359, the parser specs. Under it are #1347, the executable specs, and #1357, a parser fix. Review those first; this PR's base moves down the stack as they merge.

What are you adding in this PR?

Theme Check in Rust: a port of @shopify/theme-check-node and the packages it uses, in three crates under crates/.

• liquid-ast: the syntax tree, as @shopify/liquid-html-parser builds it.
• liquid-parser: the parser.
• theme-check: the checks, the runner, config loading, the theme graph, the docs cache and a CLI.

It reports the same offenses as TypeScript, with the same messages, positions, fixes and suggestions:

• cargo test runs the specs from Add executable check specs #1347: every case in specs/checks (all 1,680, and each check's severity) and specs/graph (all 13).
• The CLI prints the same JSON as theme-check-node's cli.ts, byte for byte, on packages/theme-graph/fixtures/skeleton.
• It includes the fixes from Update the docs cache as a whole #1350 (the docs cache is replaced as a whole) and Report configs that extend each other #1351 (configs that extend each other are an error).

The parser builds the same trees as TypeScript, and throws the same errors: cargo test runs the parser specs from #1359, and all 415 cases in specs/parser pass. It includes the fix from #1357: an unclosed block in {% liquid %} ends where its last line does. Past 1,000 levels of nesting, a template is a syntax error, Maximum call stack size exceeded, as it is in TypeScript once Node runs out of stack. Node's limit isn't a fixed number, so a template nested between about 900 and 1,000 levels parses in Rust only. The specs give trees in the TypeScript shape, so crates/liquid-parser/tests/specs.rs prints them that way; the crate itself has no JSON.

A full run with every dependency is about 11 to 13 times faster than theme-check-node: 125 ms against 1,608 ms on Dawn. It uses about 75 MB of memory, against 400 to 750 MB.

crates/theme-check/README.md has the rules the port follows: UTF-8 byte offsets in the AST, UTF-16 positions in offenses, and JS semantics where offenses depend on them.

There are two commits:

1. Add a Rust port of theme-check. The crates, and CI:
   • A rust job runs cargo fmt --check and cargo test --locked.
   • code-quality checks that the crate's copies of the configs and the check metadata match the TypeScript, and a Rust test checks each check's definition against that metadata.
   • crates/theme-check/tests/cli.rs runs the binary on small themes: config files, extends, ignore and root, app mode, bad configs and exit codes, --autofix and deep nesting. Every expected value is theme-check-node's on the same files.
2. Version and publish the Rust crates.

Versioning and publishing

Changesets versions the crates, like everything else here. crates/theme-check/package.json is a private package, theme-check-rs, outside the fixed theme-check group. To release the crates, add a changeset for it.

• pnpm release gets a step, syncCrateVersion, that copies its version into Cargo.toml and Cargo.lock. All three crates have the same version.
• CI checks that the crates have that version, and dry-runs the publish, which builds each crate from the files it would upload.
• The crate is in both the root package.json workspaces and pnpm-workspace.yaml, since changesets reads the former.

release.yml publishes the crates to crates.io after the npm packages. It's a job of its own, publish-crates, in the crates-io environment, so no npm package runs where it can get a crates.io token.

• It authenticates with trusted publishing (rust-lang/crates-io-auth-action), so there's no token secret.
• It publishes each crate whose version isn't on crates.io yet, in dependency order, so a run that fails partway is finished by the next.
• Until theme-check is on crates.io, it publishes nothing.
• It fails if crates.io answers anything but found or not found, so an outage isn't a silent skip.

There's no changeset: 0.1.0 is published by hand once this merges.

After merge

1. Create a crates.io API token with the publish-new scope, limited to theme-check, liquid-ast and liquid-parser, with a short expiry.
2. From main, publish 0.1.0: cargo publish --workspace --locked. This needs cargo 1.90 or newer.
3. For each crate, add the owners: cargo owner --add github:Shopify-Partners:crates-publish <crate>, and one more person.
4. For each crate, add a trusted publisher in its crates.io settings: GitHub, owner Shopify, repository theme-tools, workflow release.yml, environment crates-io.
5. In the repository settings, limit the crates-io environment to main. GitHub creates it, with no rules, the first time the job runs.
6. Revoke the token.

From then on, a changeset for theme-check-rs releases the crates.

What's next? Any followup issues?

• The agent server runs theme-check with this crate, in its own PR.
• cargo install theme-check doesn't get the fallback docs. They're read from a data folder next to the executable, so they need to be embedded in the binary.
• The docs cache and the remote asset checks run curl.
• The Rust CI job runs on Ubuntu only.
• Providers has one flag, and every caller sets it to true, so it can go.

What did you learn?

Changesets reads the root package.json workspaces before pnpm-workspace.yaml. A package that's only in pnpm-workspace.yaml is invisible to it.

Tophatting

• cargo test runs the unit tests, the CLI tests and the specs.
• To compare the CLI with theme-check-node. Their stderr logs differ, so compare stdout:

  pnpm build:ts
  diff <(cargo run -q --release -- packages/theme-graph/fixtures/skeleton 2>/dev/null) \
       <(node packages/theme-check-node/dist/cli.js packages/theme-graph/fixtures/skeleton 2>/dev/null)

• To try a release, add a changeset for theme-check-rs and run pnpm release. Cargo.toml and Cargo.lock get the new version.

Before you deploy

• My feature is backward compatible

🤖 Generated with Claude Code