Shopware Custom Fields Sync Laravel Package

Product Decisions This Supports

• Build vs. buy for schema-as-code. Shopware 6 custom fields are created through the Admin UI and live only in the database, so dev, staging, and production drift apart silently. This package is a candidate answer to "how do custom fields get into every environment deterministically?" — the decision is whether to adopt it, fork it, or spend a sprint writing an equivalent console command.
• Roadmap: environment parity and CI/CD hardening. If a near-term milestone includes automated deployments or reproducible store setups, custom-field provisioning is a blocking gap. This package makes custom fields a deployable artifact rather than a manual checklist item, which is the same category of work as config-as-code for payment/shipping settings.
• Use cases it unlocks: onboarding a new developer or agency without a "click these 40 fields in the admin" runbook; spinning up ephemeral staging/demo environments; promoting a feature branch whose product attributes need new fields; cleaning up orphaned field sets left behind by uninstalled plugins.
• Use case it doesn't unlock: end-customer-facing customization. This is internal tooling for the delivery team, not a merchant feature — don't let it into customer-facing roadmap conversations.
• Reduced time-to-value for multi-store or agency portfolios. The value scales with the number of environments and field definitions you manage; a single-store, single-environment shop gets almost nothing from it.

When to Consider This Package

Consider it when all of the following hold:

• You are on Shopware 6 and already run (or plan to run) more than one environment, or you rebuild environments regularly.
• You have, or expect, a non-trivial number of custom fields — enough that manual recreation is error-prone, roughly dozens rather than a handful.
• You are comfortable vendoring or forking it. With zero stars, zero dependents, and no visible community, treat it as sample code you own, not a dependency you consume. Budget for a code read, a security review, and a test pass before it touches production.
• You need the delete half of the story. Most in-house solutions only create fields; safe removal of stale fields is the genuinely annoying part and the main differentiator here.
• You want a shortcut to a working implementation rather than an original design — using it as a reference for your own command is a legitimate, low-risk way to "consider" it.

Look elsewhere (or build internally) when:

• You have one environment. The problem doesn't exist yet.
• Native migrations are sufficient. Shopware plugin migrations can insert custom_field_set / custom_field records directly. That's more code but zero third-party risk and versioned alongside the plugin that needs the fields. For most teams this is the correct default.
• You need a supported vendor. For a client project with an SLA, an unmaintained single-author package is a liability. Prefer the Shopware Store's commercial custom-field plugins or your own code.
• You need drift detection rather than drift correction. A sync tool that writes to production on every run can mask problems; if your governance requires approval gates, you want a diff-and-report tool instead.
• Deletion semantics are unclear for your data. Custom field values live in custom_field JSON columns on entities. A removal feature that drops field definitions can orphan data. Until you've verified exactly what it deletes and when, do not run it against production.

How to Pitch It (Stakeholders)

For executives: Custom fields are how we store product, customer, and order attributes outside the core schema — pricing tiers, compliance flags, ERP IDs. Today those definitions are hand-entered in each environment, which makes releases slower and creates a class of bugs that only appear after deployment. This package lets us treat those definitions as versioned code so every environment is identical by construction. It's small, unproven open-source code, so the recommendation is to evaluate it as a reference implementation and likely absorb it into our own codebase rather than take it on as a supported dependency — capping cost at a few engineering days while removing a recurring source of release risk.

For engineering: It's a Shopware bundle that creates, updates, and removes custom field sets and fields programmatically, presumably driven by console commands and/or bundle lifecycle hooks. Zero stars and zero dependents means no community validation, no compatibility guarantees across Shopware minor versions, and no guaranteed security posture — read the source, pin or vendor it, and wrap it behind our own command. Before any production use, confirm: (1) whether removal also purges stored values on entities, (2) whether it's idempotent and safe to re-run on every deploy, (3) whether it handles translations and config JSON correctly, and (4) whether it touches custom_field_set_relation. If any of those are shaky, port the logic into a migration-backed internal tool — the concept is worth keeping even if the package isn't.