Zest Jq Laravel Package

Product Decisions This Supports

• Build vs. buy vs. don't build: This is a "don't build" input, not a buy. wikimedia/zest-jq is a Composer-packaged front-end asset (the Zest CSS selector engine's jQuery plugin), produced so MediaWiki's ResourceLoader can version and ship JS dependencies. It does not give a Laravel application any PHP-side capability — no service provider, no facade, no Blade integration, no query builder.
• Front-end selector strategy: The only decision it meaningfully informs is how client-side code matches DOM nodes. If your product surface is a MediaWiki extension, skin, or gadget, adopting it aligns you with upstream and avoids hand-vendoring a JS file. For a standard Laravel + Vite/Livewire/Inertia stack, the decision it informs is "use querySelectorAll / the framework's existing DOM tooling" — this package doesn't change that answer.
• Ecosystem/parity decisions: Relevant if the roadmap includes interoperating with Wikimedia code (extensions, gadgets, Parsoid-adjacent tooling) where matching upstream behavior and version pinning matters more than community support.
• Roadmap weight: Effectively zero. With 1 GitHub star, 0 dependents, and an opportunity score of 0.005, this is not a differentiator, not a moat, and not something to schedule work around. Treat it as an infrastructure detail if it ever appears, not a product bet.
• Risk/portfolio decision: It's MIT-licensed, small, and stable, so the cost of inclusion is low — but the cost of reliance is also unrewarded, since support runs through Gerrit/Phabricator rather than GitHub issues.

When to Consider This Package

Adopt only when all of these hold:

• You are building inside or alongside the MediaWiki/Wikimedia ecosystem (extension, skin, gadget, or a tool that must stay byte-compatible with upstream ResourceLoader modules).
• You specifically need the Zest-backed jQuery selector plugin as a Composer-managed JS asset, not a PHP library.
• Your team already accepts the Gerrit contribution workflow and Phabricator-style support; GitHub is a read-only mirror, so PRs and issues filed there go nowhere.

Look elsewhere when:

• You're building a conventional Laravel product. Use native querySelectorAll, your existing jQuery/Alpine/Vue setup, or a maintained selector library — there is no Laravel integration here to justify the dependency.
• You need server-side CSS selector matching (e.g., parsing or validating selectors in PHP). Look at symfony/css-selector, wikimedia/zest-css-style PHP engines, or sabberworm/php-css-parser instead; this package is the wrong layer of the stack.
• You need commercial support, active issue triage, or a community to lean on. One star and zero dependents means you are the support channel.
• You're optimizing for long-term maintainability by an unrelated team — a mirrored repository with non-standard contribution paths is a recurring onboarding tax for every engineer who touches it.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed front-end utility that exists so Wikimedia can version a JavaScript selector plugin through Composer. It's free and low-risk, but it delivers no product capability for our Laravel application, has essentially no external adoption (1 star, 0 dependents), and offers no commercial support. Recommendation: decline for now. Including it would add a dependency whose maintenance and contribution path live outside our normal workflow, in exchange for functionality our platform already provides natively.

To engineering: If we ever build MediaWiki-adjacent front-end code, pull this in to stay in lockstep with upstream rather than vendoring a JS file — it's MIT, stable, and the version pin is the point. Otherwise, skip it: there's no PHP surface, nothing to register in a service provider, and querySelectorAll covers the same ground with zero dependencies. If someone does add it, document that issues go to Gerrit/Phabricator, not GitHub, so nobody wastes a sprint filing a PR against a mirror.