Atomic Design Bundle Laravel Package

Product Decisions This Supports

• Framework upgrade readiness (build vs. defer): v1.0.12 adds support for sensio/framework-extra-bundle v6. This removes a concrete blocker for teams planning a Symfony 5.x-era dependency upgrade — the roadmap item can move from "blocked on third-party compatibility" to "schedulable."
• Multi-surface / multi-build front ends: allowing the Assets package name to be configured means one application can serve multiple Encore builds (e.g. storefront vs. admin, or per-bundle assets) without custom glue code. This is a product-enabler for splitting a monolithic front end or introducing a second design system incrementally.
• Build vs. buy: the package is thin integration glue between the app and Webpack Encore (manifest parsing, Twig helpers, versioned asset URLs). Building this in-house is low differentiation and ongoing maintenance; buying/adopting is the rational default.
• Release risk triage: this is a patch-level release with no breaking changes, so it should be handled as routine dependency hygiene rather than a planned migration — no design, QA, or documentation workstream is triggered.
• Use cases it unblocks: asset versioning/cache-busting in production, per-environment asset manifests, and named-package asset resolution for teams running parallel builds.

When to Consider This Package

Adopt when:

• The application is a PHP/Symfony (Flex-based) app using Webpack Encore as its asset pipeline.
• You want Twig/encore_entry_link_tags-style helpers and manifest.json-driven versioned URLs without writing and maintaining that plumbing yourself.
• You run more than one Encore build or use a non-default asset package name — the new configuration option directly addresses this.
• You are on, or planning to move to, a Symfony version that resolves sensio/framework-extra-bundle v6 and need the bundle to accept it.

Look elsewhere when:

• The stack is Laravel-native — Laravel ships Vite (and historically Mix); this bundle is not the right integration point there.
• The asset pipeline is Vite, esbuild, Parcel, or Rollup rather than Webpack Encore.
• You only need Encore's output in plain PHP with no framework integration — use webpack-encore directly and skip the bundle.
• You are pinned to an older Symfony / framework-extra-bundle line and cannot take the dependency bump — stay on a prior 1.0.x and track this release for the eventual upgrade.

How to Pitch It (Stakeholders)

For executives: This is a routine, low-risk maintenance release of an open-source asset-integration library — no licensing cost and no migration project. Its practical value is unblocking a planned framework upgrade and slightly increasing front-end flexibility. Approve it as part of the normal dependency refresh; no dedicated budget or timeline is required.

For engineering: Version 1.0.12 is a patch release of the Webpack Encore integration bundle with two changes: (1) it now accepts sensio/framework-extra-bundle v6, which clears a Composer dependency conflict ahead of the Symfony upgrade; (2) the Assets package name is now configurable, so named/custom Encore packages can be wired via configuration instead of code. There are no breaking changes, no deprecations, and the upgrade surface is a composer update. Recommendation: fold it into the next scheduled dependency sweep and validate asset rendering in one non-production environment before promoting — the only realistic failure mode is a manifest/package-name mismatch in apps already using custom Encore package names.