Add JSON schema for theme info

[dmerand]

WHY are these changes introduced?

theme info --json has two established result shapes, but neither is discoverable as a command contract.

Related to shop/issues-develop#23691

WHAT is this pull request doing?

• Add a schema for the existing theme and environment JSON results.
• Preserve both JSON shapes, text output, and per-environment emission.
• Move JSON/text selection to the command result boundary.
• Record opening and closing analytics timings in both text and JSON modes.

Normal output remains human-readable sections:

Theme Configuration
Store                 my-shop.myshopify.com
Development Theme ID  Not set

Tooling and System
Shopify CLI  3.91.0
OS           darwin-arm64
Shell        /bin/zsh
Node version v24.15.0

The matching JSON output remains:

{
  "store": "my-shop.myshopify.com",
  "development_theme_id": null,
  "cli_version": "3.91.0",
  "os": "darwin-arm64",
  "shell": "/bin/zsh",
  "node_version": "v24.15.0"
}

A multi-environment invocation continues to emit one existing JSON document per environment. This PR does not add a wrapper or change that public behavior.

Validate non-interactive requirements after loading each environment, so configured theme IDs work while conditional safety flags remain required. Environment notices use JSON diagnostics in JSON mode. Unsupported multiple environments and a global --path now fail with a nonzero exit code; confirmation prompts use the stable command ID.

How to manually test your changes?

shopify theme info
shopify theme info --json
shopify theme info --json-schema
shopify theme info --environment development --environment staging --json

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• A single changeset for all theme migrations is added in the last PR, #8682.

[gonzaloriestra]

/snapit

[github-actions]

🫰✨ Thanks @gonzaloriestra! Your snapshot has been published to npm.

Test the snapshot by installing your package globally:

pnpm i -g --@shopify:registry=https://registry.npmjs.org @shopify/cli@0.0.0-snapshot-20260915114646

Caution

After installing, validate the version by running shopify version in your terminal.
If the versions don't match, you might have multiple global instances installed.
Use which shopify to find out which one you are running and uninstall it.

[gonzaloriestra]

I think we don't need this with the help and new instructions from the skill, I'll remove it.

[fredericoo]

blocking: let's redact store-password before emitting these diagnostics too. The reporter only masks the exact password key, so an environment's storefront password is included in full in the JSON diagnostic message. theme profile --environment preview --json supports this field. The text banner already had this redaction gap, but this branch now sends the secret through the structured event channel as well. Redact both credential fields before building items, and extend the diagnostic test to check that the full storefront password never appears in emitted events.

[gonzaloriestra]

Both credential fields are now masked

[fredericoo]

blocking: let's use an assertion-free property check instead of as unknown as {multiEnvironmentsFlags?: RequiredFlags} here. This hook only needs to know whether the constructor defines the metadata. The double assertion bypasses compiler checks and isn't needed:

const command = this.constructor
if (
  'multiEnvironmentsFlags' in command &&
  command.multiEnvironmentsFlags !== undefined &&
  Array.isArray(flags.environment) &&
  flags.environment.length > 1
) {
  return
}

Keep the undefined-versus-null distinction: own-runner commands without this metadata must retain parse-time validation. Don't add a default of null to the base class.

[gonzaloriestra]

Replaced the double assertion with the suggested property check. The undefined-versus-null distinction is preserved.

[fredericoo]

blocking: let's assert that these timings bracket the work, rather than only checking two identical calls. Moving the closing timing immediately after the opening timing still passes this test in both modes, even though the duration excludes fetching and presenting the result. Check that only the opening timing exists while the fetch is pending, then that the closing timing is recorded after presentation.

[gonzaloriestra]

Both modes now verify that only the opening timing exists while fetching is pending, and that presentation happens before the closing timing

[fredericoo]

blocking: let's keep checking the branch-specific recovery advice as well as the rejection. Both modified tests now assert the same heading, so they still pass if the missing-file case tells users to edit a configuration file that does not exist. Assert the AbortError guidance for each case.

[gonzaloriestra]

Both cases now assert the AbortError and their specific recovery advice, using real temporary files in theme-command-environments.test.ts

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/node/base-command.d.ts

@@ -35,6 +35,7 @@ declare abstract class BaseCommand extends Command {
         argv: string[];
     }>;
     protected environmentsFilename(): string | undefined;
+    protected validateNonTTYFlags(flags: FlagOutput): void;
     protected failMissingNonTTYFlags(flags: FlagOutput, requiredFlags: string[]): void;
     private failMissingNonTTYFlagRequirements;
     private applicableNonTTYFlagRequirements;