shopware/shopware-cli/shopware-cli-extension-store

Shopware Store readiness

Assess the current extension for Store publication. Start immediately. Never modify files. Never ask a preflight question the workspace can answer.

Every claim in the answer carries a source. A finding without a source is not a finding.

1. Collect evidence

Gather evidence in two steps: run shopware-cli directly — exactly as a developer would — then read a few of the extension's own files (listed below) for the specific values the classification table needs. Do not wrap this in a bespoke script: calling the CLI directly keeps the output and the config-file discovery identical to what a human gets, and avoids re-implementing logic (e.g. config-path lookup) the CLI already owns.

Run both validations from the extension root and capture the full output and the exit code:

shopware-cli --version
shopware-cli extension validate . --only builtin --format markdown
SHOPWARE_CLI_STORE_COMPLIANCE=1 shopware-cli extension validate . --only builtin --format markdown

• The exit code is the pass/fail signal (0 = pass, non-zero = findings).

The report goes to stdout; a usage block or error goes to stderr — do not read a validation failure as a usage error.

• --format markdown gives a stable, quotable form. --reporter is a

deprecated alias that prints a warning — use --format.

• Configure validation.store_compliance: true in the extension configuration,

or set SHOPWARE_CLI_STORE_COMPLIANCE=1, to enable Store compliance checks for Administration and Storefront assets. Treat that run as a delta over the normal run: report only the lines it adds.

• extension validate now runs all checkers by default. The two commands above

explicitly select only the built-in builtin checker, not PHPStan/ESLint/Stylelint. (sw-cli remains accepted as a legacy alias. It is that checker's deprecated name, not shorthand for the binary.) Report "the builtin checks passed", not "full validation passed". Source: cmd/extension/extension_validate.go, selectExtensionValidationTools.

• The Markdown report includes a checker table. invoked means the checker was

called; it does not prove that files were analyzed or that a check passed. skipped means it was not selected or was excluded. Classify only finding lines, not checker-status lines.

• Use one shopware-cli binary throughout, and state its version. Never mix

binaries mid-answer.

• Each error line ends with its result identifier — that identifier is the row's

Source, and L0 catches any line the table does not name explicitly. The CLI currently prints a missing icon twice; count a repeated line once.

Then read these files yourself for the measured values and precondition triggers the classification table below uses — read only these, and do not re-derive CLI findings:

• composer.json — license, extra.label, authors, and per-locale

extra.description / extra.manufacturerLink / extra.supportLink (L1–L3, L5, A1, and the R9 trigger).

• src/Resources/config/plugin.png — presence, dimensions, and size (the L4

gate; a missing icon is the CLI's metadata.icon line under L0).

• src/Resources/config/config.xml — presence, and whether fields carry an

English fallback (the R10 trigger).

• extension type (plugin / theme / app) and whether it ships CMS elements (G3 /

G4 triggers).

Run shopware-cli extension config-schema only if the extension already uses Store sync config, or the user asks where Store metadata is configured. Schema fields are never readiness requirements.

Do not answer before both validations have run.

2. Classification table — the only place classification is decided

Copy Level, Target, and Source from this table verbatim. Do not re-derive them from doc prose, CLI output, or reasoning. If a source has changed, report the drift as a separate note; do not silently reclassify.

Doc baseline: https://developer.shopware.com/docs/guides/development/testing/store/content-and-translations.html Code baseline: the shopware-cli source. The result identifiers below are printed at the end of every CLI result line and are stable across releases.

CLI rules are cited by their result identifier, not a file or line number: identifiers appear in the CLI's own output and survive refactors. If a shopware-cli source checkout is at hand, a row can be re-checked with:

grep -rn '"metadata.icon.size"' --include=*.go internal/ | grep -v _test