Tringify CLI

The Tringify CLI is the tringify command for theme development. It creates a theme from the starter, previews and validates it, adds it to a development store, and publishes versions to your theme listing, signing in with your Tringify account. It is open source at github.com/tringify/cli.

On macOS or Linux, run:

The installer downloads the release for your platform, verifies it against the published SHA256SUMS, and installs tringify in ~/.local/bin. On Windows, run this in PowerShell:

It verifies the download the same way, installs tringify.exe in %LOCALAPPDATA%\Programs\tringify and adds that folder to your path; open a new terminal afterwards. Releases cover macOS (Apple silicon and Intel), Linux (x86-64 and ARM64) and Windows (x86-64, which also runs on Windows on Arm). Set TRINGIFY_CLI_VERSION to install a specific release. Run tringify version to confirm.

The CLI is a single program and needs nothing else installed: no Python, Node.js or other runtime. The first time you check, package or preview a theme, it downloads the theme validator (themecheck) and preview renderer (theme-preview-render) from the theme tools release for your platform, verifies them against that release's SHA256SUMS, and keeps them in your user cache folder:

The CLI looks for a newer theme tools release at most once a day and keeps working offline with the one it has. Set TRINGIFY_THEME_TOOLS_VERSION to use a specific release, TRINGIFY_THEME_TOOLS_HOME to keep the two programs in another folder, or TRINGIFY_THEME_CHECK and TRINGIFY_THEME_PREVIEW to use copies you already have.

Edit sections in src/sections/<name>/ as body.html, style.css and schema.json, and keep src/.generated-sections.json in version control: it records which compiled files build generated, so removing a section's source also removes its compiled file, and a compiled file you edited by hand is never deleted. If you used the tringify-theme command from the theme tools, each of its commands is available as tringify theme <command> with the same rules and output, on the same theme files.

Create the listing in the Developer Portal under Themes first; the listing holds the name, pricing and review details. Then publish from a clean git checkout:

diff shows the files that change compared with the newest published version. publish refuses to run when the git work tree has uncommitted or untracked changes, so every version matches a commit. It shows the same comparison and asks before publishing; pass --yes to skip the question, for example in CI. It then packages the theme, uploads and validates it, publishes the version, and adds Source commit: <sha> to its release notes. Add --install-store STORE_ID to also install the new version, unpublished, into one of your organization's development stores. A published version cannot change; publish a new version number for every update, and use tringify theme pull --listing LISTING_ID --version X.Y.Z to get any published version back exactly.

theme dev adds the theme to the store's primary storefront as an unpublished theme, then watches your files. Every time you save, it builds the theme, validates it and syncs it to that store, usually in a few seconds; refresh the theme preview in Store Admin to see the change. A change that fails validation prints the error and syncs nothing. The theme it uses is remembered in .tringify/dev.json, so the next run continues with the same theme; keep .tringify/ out of git. It never touches the store's published theme. Use --storefront to choose another storefront and --theme to sync into another unpublished theme added from a package.

push adds a separate copy each time it runs. pull downloads a store theme, for example one changed in the Store Admin code editor, into a new folder; the files are compiled, so sections are .vasc files rather than src/ folders.

A theme can ship a demo catalog: demo/catalog.json and the images in demo/images, the same pack the Theme Store uses for its previews. --with-demo adds it to a development store so you can build against the catalog the theme was designed around. It uploads the images to the store's Media, then creates the products with their options, variants and vendors, priced in the store's currency, and turns each demo collection into a tag on its products and a collection for that tag.

It runs on development stores only. Products and collections whose handle the store already has are left as they are, and only the images of the ones it adds are uploaded, so running it again adds only what is missing and never changes or duplicates anything. Products appear under Products within a minute. The first run with the flag asks you to approve product and file access for that store.

tringify login uses OAuth with PKCE and a one-time listener on 127.0.0.1; your password never passes through the CLI. On the approval screen you choose the developer organization, or the store for login --store, and see exactly what the CLI asks for:

The CLI never has more access than your own role, and it follows changes to your role. It cannot change a live theme, delete stores, create listings or change pricing. If you signed in before development store access was added, run tringify login again to use the store commands. Tokens are stored only in your system keychain: the macOS Keychain, Windows Credential Manager, or the Secret Service on Linux (GNOME Keyring or KWallet). Without one, sign-in stops and says so. Access tokens last 15 minutes and are refreshed automatically; refresh tokens rotate on every use. Uploads, publishes, installs and new development stores are recorded in your organization's activity log as Connected tool: Tringify CLI.

See and disconnect the CLI in your Tringify account under Connected tools, or run tringify logout. Over SSH, set TRINGIFY_NO_BROWSER=1 and open the printed sign-in URL on a machine that can reach the CLI's 127.0.0.1 listener, for example through port forwarding. AI agents can use the same operations through MCP; see Connector OAuth.