Object Factory Laravel Package

Technical Evaluation

Architecture fit. wikimedia/object-factory is a framework-agnostic PHP utility that turns declarative configuration arrays into instantiated objects (class name, constructor args, fluent calls, and optional service injection). It is not a Laravel package: there is no service provider, facade, config stub, or container contract integration. Its core job — resolving a class name plus arguments into an object — overlaps almost entirely with Laravel’s service container. The genuine gap it fills is narrow: a config-driven plugin/strategy registry where administrators or config files name concrete classes and their constructor arguments, and you want that resolved without writing a bespoke resolver. For a typical Laravel app, that is a convenience, not a capability the framework lacks.

Integration feasibility. Technically trivial. composer require the package, and you can call its factory from anywhere; a thin wrapper (a Laravel service provider binding a singleton, plus a config schema) is a half-day of work. No bootstrapping conflicts, no global state, no framework hooks. The risk is not "can we integrate it" but "should we."

Technical risk.

• License (dominant risk): GPL-2.0. For any proprietary or SaaS product where the code is distributed or where legal counsel treats copyleft conservatively, this is a blocking issue. MediaWiki libraries are not permissively licensed, and this one is not an exception.
• Governance: The GitHub repo is an explicit read-only mirror; contributions go through Wikimedia Gerrit. You cannot open a PR, and upstream priorities are MediaWiki’s, not yours.
• Maturity signal vs. reality: 5 stars and 0 dependents understates real-world usage (MediaWiki core uses it heavily), but within the Composer/Laravel ecosystem it has essentially no community, no Stack Overflow footprint, and no third-party tutorials.
• Scope creep risk: Config-driven instantiation moves wiring decisions out of code and into configuration, which complicates static analysis and traceability.

Key questions.

1. What is our legal posture on GPL-2.0 dependencies in this codebase, and does this library ship to customers or run server-side only?
2. Is the config-to-object use case real and recurring, or are we solving a single call site?
3. Could Laravel’s container (app()->makeWith(), contextual bindings, tagged bindings) cover 90% of the need with a ~50-line custom resolver?
4. Do we actually need calls/service-injection semantics, or only class + args?
5. Which PHP versions must we support, and does the current tag align?
6. If we adopt it, do we accept a read-only mirror with Gerrit-only fixes, or do we vendor/fork (and inherit GPL obligations on the fork)?

Integration Approach

Stack fit. Compatible with modern PHP/Composer and coexists with Laravel without conflict, but it sits beside the container rather than inside it. Any adoption requires an explicit decision about which resolver owns instantiation — you do not want two competing object-construction paths in one codebase.

Migration path. There is no migration path from anything, because nothing depends on it. The realistic path is greenfield: introduce it for a new config-driven subsystem (e.g., selectable export formats, webhook handlers, payment adapters) rather than retrofitting existing new/container calls. Retrofitting would be churn with no functional gain.

Compatibility. Verify the tag’s PHP constraint against the application’s floor, and confirm autoloading and any transitive Wikimedia dependencies are acceptable under the same license review. Because it has no Laravel integration, there is no version-matrix risk against the framework itself — only against PHP.

Sequencing.

1. Legal/licensing gate first. Nothing else matters if GPL-2.0 is disallowed. Do this before any spike.
2. Spike the container-native alternative. Prototype the same behavior with a small resolver over app()->makeWith(). If it satisfies the requirement, stop — the dependency adds license and governance cost for no functional gain.
3. If the library wins, wrap it in a single application-level service (provider + typed facade), define a versioned config schema, and forbid direct static calls outside the wrapper.
4. Pin the version and vendor-lock, documenting the Gerrit-only contribution model in the ADR so future maintainers do not attempt GitHub PRs.
5. Defer until a second use case appears. One consumer does not justify a dependency with this license profile.

Operational Impact

Maintenance. Upstream moves at Wikimedia’s cadence, gated by MediaWiki’s release cycle; security fixes arrive on that schedule, not ours. The mirror is read-only, so we cannot patch upstream and must either wait or maintain a local fork (with the GPL obligations that implies). Budget for periodic manual review of Gerrit activity, since Composer will not surface advisories for a package this small.

Support. No commercial support, no vendor, no meaningful community. Internal staff become the support tier. Onboarding documentation will have to be written in-house.

Scaling. Runtime cost is negligible — it is reflection/instantiation, not a hot path. The operational scaling concern is cognitive: config-driven object graphs become hard to trace as the config surface grows, and IDE navigation ("where is this class instantiated?") degrades. Keep the config surface small and schema-validated.

Failure modes.

• Misconfiguration detected late: a bad class name or argument list in config fails at instantiation time, not at boot. Add a startup validation pass that resolves every configured spec in a dry-run/test context.
• Silent drift: constructor signatures change and config silently breaks in an untested code path. Mitigate with contract tests per configured class.
• License contamination: the highest-severity failure mode, and the one with no runtime signal — it surfaces in diligence or distribution review.
• Governance dead-end: a required fix blocked behind Gerrit review with no SLA.
• Two resolvers: container bindings and config-driven instantiation diverging, producing instances with different lifetimes or dependencies.

Ramp-up. Engineer ramp-up is low — the API is small and the concept familiar to anyone who has used a DI container. Organizational ramp-up is the real cost: every new contributor must learn "this one subsystem resolves objects differently from the rest of the app," and legal must re-clear the dependency at each acquisition or distribution event.

TPM recommendation. Treat as evaluate-and-hold. Score 0.025 with 0 dependents and a GPL-2.0 license is a defensible "no" for a Laravel codebase unless a concrete, recurring config-driven plugin requirement exists and the container-native alternative has been explicitly rejected. If adopted, it should be a single, wrapped, version-pinned dependency — never a pattern the team is encouraged to reach for generally.