Attribute Group Readonly Bundle Laravel Package

Getting Started

This is a small, low-traffic Symfony-style bundle (AttributeGroupReadonlyBundle) that was just bumped to 2.0.0 — a major version whose only shipped change is "split into two configurations." There is no prior assessment on file, so treat everything below as a first-pass evaluation you should validate against the actual README and config/ tree in the tagged release.

Minimum steps:

1. composer require inuartech/attribute-group-readonly-bundle:^2.0 — pin the major explicitly. There is no 1.x compatibility layer documented in the changelog.
2. Read the config files first, not the README. The 2.0 headline change is that a single configuration surface was split into two; the README screenshots/code samples are the most likely thing to be stale on release day. Open the package's config/ directory (or the DependencyInjection/Configuration.php node tree) and confirm the actual root keys before copying any snippet.
3. Register the bundle. If you are in a Laravel app rather than Symfony, this is the first real decision point — check for a Laravel service provider or facade. A package named *Bundle with a DependencyInjection extension typically has neither, which means manual container wiring and no config publishing. Confirm before you invest further.
4. First use case: take one entity/DTO with a single attribute group and make it readonly, then assert the behaviour in a test before rolling it across the model layer. With a 2.0.0 released with a single PR and a first-time contributor, you want a one-file blast radius.

Implementation Patterns

Configuration-first, attribute-second. The 2.0 split implies the package now distinguishes two concerns that used to share one config node — most plausibly a global default plus per-group (or per-entity) overrides. Structure your own config accordingly: set the opinionated default once, then override narrowly per attribute group. Resist the urge to enumerate every group explicitly; that's the config you'll be rewriting at 3.0.

Wrap it behind your own abstraction. Because the package is pre-adoption and the 2.0 diff is undocumented in detail, do not let #[...] attributes or config keys from this package leak into 50 files. Put a thin layer in front — a base DTO/entity trait, a form type extension, or a normalizer decorator — so that a 2.0.1 or 3.0.0 pin change is a one-file edit.

Treat the two configs as environments of each other. In practice, "two configurations" usually means you can run the readonly enforcement in one mode (hard failure) and another (soft/no-op). That maps well onto test vs. production: enforce strictly in CI so a mutable-groups regression fails the build, and keep the no-op path available for local fixtures where you need to mutate objects to set up state.

Upgrade path for existing 1.0.5 users. Since this is a major bump with a single behavioural change, do the migration as a dedicated PR: republish/compare the config, diff old keys against new, delete the dead keys rather than leaving both, then run the full suite. Do not bundle this with feature work — there's no deprecation shim to catch you.

Integration tips. If you're on API Platform, this is the natural pairing (attribute groups driving serialization, readonly enforced on the output model). In Laravel, the equivalent slot is API Resources plus $guarded/readonly properties — evaluate whether a ~single-PR package is worth the wiring versus a 20-line base class of your own.

Gotchas and Tips

• The changelog is the entire documentation for this release. "Split into two configurations" does not tell you which key moved, whether old keys are aliased, or whether both configs are required. Diff the Configuration.php between 1.0.5 and 2.0.0 tags before upgrading — that's the authoritative migration note.
• Assume the config is a hard BC break. Major version + "split config" + no mention of backward compatibility almost always means old keys are silently ignored rather than throwing. Silent misconfiguration here means readonly enforcement quietly stops working. Add a test that asserts enforcement actually fires, not just that the container boots.
• Clear caches on both sides of the upgrade. Container/config caching will happily serve you a stale compiled container from before the split, which looks exactly like "the upgrade did nothing."
• *Bundle in a Laravel app is a smell. No package auto-discovery, no config/*.php publishing, no facade. If the repo has no Laravel service provider, budget for writing one or pick a different approach.
• Single-maintainer, first-time-contributor release. 2.0.0 is essentially PR #1. Pin exactly (2.0.0 or ~2.0.0), commit the lock file, and read the diff of every patch release for the next few months. Set a calendar reminder to reassess adoption in a quarter.
• Debugging enforcement failures: log the resolved effective config (both halves) at boot in non-production. When a group that should be readonly mutates anyway, the cause is almost always config resolution order, not the attribute itself.
• Extension points: the attribute class and the DI extension are the two seams worth knowing. If you need behaviour the package doesn't offer, a compiler pass decorating the extension is cleaner than forking — and far cheaper to abandon if the package stalls.
• Verdict for this release: not a reason to adopt, and a reason to be careful if you already have. The change is plausible housekeeping, but a major version with one undocumented-in-detail PR and no migration guide is a signal about maintenance velocity. Adopt only if the two-config split maps directly onto a problem you have today.