--- title: 'Code Quality, Logging, and Packaging | Shopware Community Hub' description: >- Learn how to prepare review-ready code, logging, JavaScript sources, dependencies, and release packages for Store extensions. canonical_url: >- https://hub.shopware.comhttps://hub.shopware.com/learn/unit/code-quality-logging-and-packaging --- # Code Quality, Logging, and Packaging - Structure the codebase in a review-ready and maintainable way. - Implement logging in a traceable and secure manner. - Provide JavaScript sources and compiled assets transparently. - Prepare Composer dependencies and ZIP structures professionally. - Keep debug and development artifacts out of Store releases. # Code Quality, Logging, and Packaging A Store-ready extension is not only defined by its features. It also needs a codebase and release package that can be reviewed, understood, installed, and maintained. This means partners need to think about code quality, logging, JavaScript sources, Composer dependencies, and packaging before the extension is uploaded. In this unit, you will learn what a review-ready release should contain and which artifacts should stay out of the Store package. ## Code Quality Is Part of Store Readiness The code quality documentation explains that Store extensions must pass automated code review, including checks such as PHPStan and SonarQube. They are also manually reviewed for security, standards, user experience, and behavior. This means code quality is not only an internal development concern. It becomes part of the publication process. A review-ready codebase should be: - readable for reviewers - limited to necessary files - structured around clear responsibilities - free of development-only artifacts - traceable in its dependencies - prepared for maintenance after publication The important mental model is this: > A Store package should contain the extension as a product release, not the full working directory of the development team. This helps reviewers understand the extension and helps merchants receive a clean, production-ready package. ## Avoid Blocker Patterns and Debug Artifacts Some code patterns are not acceptable in Store releases. The code quality documentation lists blocker patterns such as: - `die` - `exit` - `var_dump` These patterns are typical development shortcuts. In a Store extension, they can interrupt normal shop behavior, leak information, or make errors harder to handle properly. Partners should also keep debug and development artifacts out of release packages. Examples include: - unused resources - local test files that are not part of the release - temporary debug scripts - development-only configuration - unnecessary generated files - files that are not needed for installation or runtime The goal is not to hide the development process. The goal is to ship a clean release artifact. ## Logging Should Be Traceable and Safe Logging helps partners and merchants understand what happened when something fails. But logging also needs boundaries. The Store quality rules require logs to be written under Shopware's log directory, such as `/var/log/`. Logs must not be reachable through a public URL and should not be written into random paths. The plugin logging documentation describes how plugins can use Monolog channels and handlers. A dedicated channel makes logs easier to identify and allows project owners to route logs according to their needs. A good logging approach should: - write logs to the Shopware logging system - use a clear extension-specific log name or channel - avoid exposing secrets, tokens, passwords, or personal data - log enough context to support investigation - separate merchant-facing messages from technical log detail For payment extensions, the Store quality documentation also notes that the plugin logger service must be used. ## JavaScript Sources Must Be Reviewable If an extension ships JavaScript, reviewers need access to readable sources. The code quality documentation states that uncompiled, readable JavaScript should be delivered together with compiled assets. Sources should be stored in a separate folder for review, and Shopware must be able to access unminified sources. This matters because reviewers need to understand what the JavaScript does. A minified asset alone is not enough for a transparent review. For partners, this means JavaScript delivery should be planned as part of the build and release process: - keep readable source files - include compiled assets needed for runtime - avoid shipping only minified code - keep source and build output organized - remove unrelated development artifacts The Store package should make it clear which files are source files and which files are compiled assets. ## Composer Dependencies Must Be Traceable Dependencies are part of the extension's risk and maintenance profile. Reviewers and merchants need to know which external code is included. Plugin dependencies should be defined in the extension’s `composer.json`. Clear dependency declarations and a consistent package structure improve traceability and help ensure that the extension can be reviewed and maintained reliably. For Store packages, partners should consider: - Are all required dependencies declared clearly? - Are unnecessary dependencies removed? - Are private dependencies handled intentionally? - Is the package size reasonable? - Is the release archive free of development-only dependency artifacts? - Does the ZIP structure match Store expectations? For plugins, the Store quality documentation also notes that `composer.lock` should not be included in the archive and that production artifacts should be shipped. The goal is to make dependencies understandable and reviewable. ## Packaging Is a Release Step Packaging should be treated as a release step, not as a last-minute ZIP operation. A review-ready package should include what is needed to install and run the extension. It should not include everything that happened to exist in the local development folder. Before creating the final package, partners should ask: - Does the package contain only necessary files? - Are readable JavaScript sources included where required? - Are compiled assets included where needed? - Are Composer dependencies declared and handled correctly? - Are logs, caches, temporary files, and local debug files excluded? - Is the package reproducible from the repository or build process? This makes releases more predictable and easier to repeat for future versions. ## Example: Preparing a Release Package Imagine a partner prepares a plugin for Store submission. During development, the repository contains source code, tests, local debug files, build output, JavaScript sources, compiled assets, and Composer dependencies. For the Store release, the partner should not simply zip the whole directory. Instead, they should prepare a production package: - remove temporary debug files - remove unused resources - ensure blocker patterns such as `var_dump` are gone - include readable JavaScript sources and compiled assets - declare required Composer dependencies - exclude files that should not be part of the Store archive - verify that logging writes to the expected Shopware log location This package is easier to review and safer for merchants to install. ## Common Pitfalls ### Shipping the Development Folder as the Release Package A local development folder usually contains more than a Store release needs. Package only what belongs in the production artifact. ### Leaving Debug Statements in the Code Patterns such as `die`, `exit`, and `var_dump` can fail review and can break normal shop behavior. ### Providing Only Minified JavaScript Reviewers need readable JavaScript sources. Compiled assets alone are not enough. ### Logging in the Wrong Place Logs should use Shopware's logging system and should not be publicly reachable or written into arbitrary paths. ### Adding Dependencies Without Reviewing Them Every dependency increases maintenance and review responsibility. Include only what is needed and keep dependencies traceable. ## Summary - Store-ready code should be readable, maintainable, and free of development-only artifacts. - Blocker patterns such as `die`, `exit`, and `var_dump` should not appear in release code. - Logging should use Shopware's logging system and avoid sensitive data. - JavaScript sources and compiled assets should be provided transparently. - Composer dependencies and ZIP packages should be prepared as controlled release artifacts. Next, you will connect listing quality, lifecycle behavior, and release packaging in the course overview for Store Launch, Lifecycle, and Monetization.