Breaking change and public (extension) API static analyzer CLI tool, purpose-built for Shopware commerce core developers. Intended to be run in the Shopware repository CI workflows to prevent introducing breaking changes by accident.
Note
Very much WIP and in a rewrite right now, to build things properly and start with vision part 1.
If you are looking for the previously vibe coded prototype, which reported impacted
extension usages for a breaking change (vision part 2), switch to the vibe-prototype branch
- Checkout this Repo
- Have Rust installed
- Run
cargo build --release - Afterwards you can use your executable under
./target/release/sw-impact
In general run sw-impact --help for latest CLI use instructions.
- Have the shopware codebase cloned and checkout a "base" branch you want to compare against
- Run
sw-impact index ../path/to/shopware - Make changes in your shopware codebase or checkout a different state
- Run
sw-impact check ../path/to/shopwareand see the breaking change report
Note
Step 1 and 2 might be simplified at some point, e.g. the tool could check it out itself
- Detect and flag any (possible) breaking change to the public (extension) API that the Shopware commerce core exposes
- (Optional) show (possible) impact evidence based on real extensions using the API surface, utilizing the source code of all extensions published in our own extension store.
Some design decisions to keep things simple:
- All analysis only works on a per file basis to keep it simple and performant
- All parsing happens through tree-sitter, no custom / specialized parsers per language, which aren't based on tree-sitter
.jsfiles are still parsed by theTypeScriptgrammar, to keep things simple and reuse the tree-sitter queries- Overall try to keep the codebase minimal and performant, it doesn't have to cover
every edge case, especially if it doesn't exists in Shopware's commerce core right now
- for example only support Vue options API for now, because composition API isn't really used in the core (yet)
Checkmarked means implemented.
- Admin Vue.js components (not marked
@private/@experimental/@internalin top level comment)- Component existence under their approximated registered name, either by:
import template from './sw-model-editor.html.twig';, using the last.html.twigimport that is in the same directory- fallback to extract from the file path parent folder (mostly followed convention in commerce core)
- Emit event names existence
- Computed
- existence
- signature breaks (return type)
- extended syntax (object with getter / setter)
- Methods
- existence
- signature breaks (arguments, return type, is async)
- Properties
- existence
- signature breaks (type, required)
- added required prop to existing (public) component
- Component existence under their approximated registered name, either by:
- Admin Twig templates
- block existence
- Storefront Twig templates
- block existence
- Lint output formats
- Pretty human readable
- JSON (AI / downstream readable)
- GitHub workflow PR annotations
That might or might not be implemented at some point:
-
sw-impact searchcommand, to query the shopware codebase by tree-sitter query and file type -
sw-impact inspectcommand, to inspect the tree-sitter syntax tree of a given file - further breaking change check ideas, also looking at our Backward Compatibility
guidelines.
- Entity definitions
- (optional) HTTP API schemas (currently already covered by Explore OpenAPI GH App)
- (optional) PHP code (currently already covered by Roave/BackwardCompatibilityCheck)
Basics (if you are new to Rust):
- Tests can be executed with
cargo test - Linter can be executed with
cargo clippy - Formatter can be executed with
cargo fmt - For iterating on changes, you can also execute e.g.
cargo run --release -- check ../shopware
Advanced:
- Be familiar with tree-sitter
- For building and testing tree-sitter queries:
- You can experiment with their playground
- Or in Neovim, run
:InspectTree, you can open the a query editor by pressingo