Args Laravel Package

Product Decisions This Supports

• Standardize WordPress query construction across a plugin/theme portfolio. The package replaces hand-rolled associative arrays passed to WP_Query, get_posts, get_terms, WP_User_Query, wp_insert_post, etc. with typed, discoverable arg objects. That directly informs a roadmap decision: do we keep accreting fragile array literals in every plugin, or adopt one shared, autocompleted contract?
• Build vs. buy for an internal "WP args" helper. The functional surface (typed wrappers + toArray()) is small enough that most agencies could write it, but the real cost is maintenance against WordPress core churn — new query args, deprecations, multisite nuances. Buying is the cheaper path unless you already have a platform team owning WP internals.
• Static-analysis and code-quality investment. Adopting the package is a prerequisite/enabler for running PHPStan or Psalm at meaningful levels on WordPress code, which is otherwise the single largest blocker to modernizing legacy WP codebases. This is a "how do we get to PHP 8 + typed code" roadmap input.
• Onboarding and code review cost. Typed args remove the "what keys does this array take again?" lookup loop for contractors and new hires. That's a measurable reduction in review cycles and a lever on team-scaling decisions.
• Testability and refactoring. Because args are objects, query construction becomes unit-testable and refactorable independent of the database — supports decisions about test coverage targets for WP integration layers.
• Use-case fit: agency plugin/theme development, WordPress multisite maintenance, WP-CLI scripts, and any product where meta_query/tax_query nesting has historically caused production incidents.

When to Consider This Package

Adopt when:

• You are building WordPress plugins, themes, or mu-plugins (not standalone Laravel/Symfony applications — despite the "PHP package" framing, this is WordPress-specific and offers little outside WP_Query-style APIs).
• Your projects are Composer-managed with a modern PHP floor (7.4+/8.x) and PSR-4 autoloading.
• Multiple developers or external contractors touch query code, and array-shape drift is a recurring defect source.
• You are rolling out PHPStan/Psalm and need typed query surfaces to make it viable.
• Your licensing is GPL-compatible — GPL-2.0 is a natural fit for the WordPress ecosystem but constrains proprietary redistribution in non-WP contexts.
• The specific arg sets you depend on are covered — verify coverage for your most-used queries before committing, since partial coverage creates an awkward mixed style.

Look elsewhere when:

• The application is Laravel or framework-agnostic PHP. Use DTOs, typed value objects, or spatie/laravel-data — those give you the same typing benefits with framework-native validation and serialization.
• The project cannot use Composer or must remain a single-file drop-in.
• You are submitting to wordpress.org and want to minimize bundled dependencies — GPL is fine, but vendoring an extra library is a review and support-surface decision, not a blocker.
• Bus-factor risk is unacceptable: this is a small, single-maintainer project (~119 stars). If that is a hard organizational constraint, fork it under GPL and own it, or budget for a migration-away path. Treat it as a thin, replaceable convenience layer rather than load-bearing infrastructure.
• Your team has already standardized on a different WP query-builder or a custom DTO layer — consistency beats marginal typing gains.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, low-risk developer-experience dependency for our WordPress work. It replaces error-prone array literals in database queries with typed objects, which measurably reduces a common class of production bugs — malformed meta and taxonomy queries — and shortens onboarding for contract developers. It is a small, GPL-licensed library that sits alongside WordPress core conventions rather than replacing them, so there is no lock-in: if the project stalls, we can fork or revert to plain arrays with minimal effort. Recommended decision: adopt as a standard dependency in Composer-managed WordPress projects, with a pinned version and a documented fallback.

For engineering: Typed arg objects for WP_Query, WP_Term_Query, WP_User_Query, and related APIs, with IDE autocompletion, static-analysis support, and a toArray() escape hatch at the boundary where WordPress core expects arrays. Adoption cost is one Composer line plus a style rule; migration can be incremental, file by file. Two caveats to plan around: (1) this is WordPress-specific — do not carry it into non-WP services; (2) it is a single-maintainer project on a recent release cadence, so pin the version, keep toArray() usage at the integration boundary so the dependency stays swappable, and avoid leaking arg objects into domain-layer signatures.