Pquery Laravel Package

Product Decisions This Supports

• Build vs. buy for DOM manipulation: pQuery provides jQuery-style chaining ($html->find('.card')->eq(0)->attr('href')) on top of PHP's native DOMDocument. The decision it informs is whether to spend engineering days writing CSS-selector-to-XPath glue and traversal helpers, or adopt a ready-made facade. The genuine value is ergonomics, not capability — everything it does is achievable with DOMDocument + DOMXPath + Symfony's CssSelector.
• Scraping and content-ingestion feature work: If your roadmap includes pulling structured data from third-party HTML (partner feeds, competitor pages, legacy CMS exports), a jQuery-shaped API shortens the loop between "inspect in DevTools" and "write the parser." Front-end developers can contribute without learning XPath.
• Server-side HTML transformation: Use cases like rewriting email templates, sanitizing/reshaping user-submitted markup, injecting tracking parameters into outbound links, or normalizing imported article bodies. These are small, well-bounded features where a chained selector API reads far better in review than nested DOM loops.
• Prototype velocity vs. platform standards: This package supports the "spike now, standardize later" decision — validate a parsing feature in days, then decide whether to migrate to a maintained component before the surface area grows.
• Roadmap negative decision: It should also block work — specifically, it argues against standardizing an internal parsing convention on this API, because a 2016-dated, single-maintainer, 133-star dependency creates a future migration line item you are effectively pre-approving.
• License decision: LGPL-2.1 in a distributed PHP product triggers a legal review step. For SaaS-only deployments this is usually a non-issue; for shipped/on-prem software it becomes a genuine go/no-go gate that belongs in the decision log, not in a code review comment.

When to Consider This Package

Consider it when:

• The consumer is internal tooling, a one-off migration script, or a throwaway scraper — code with a bounded lifespan and no public API surface.
• Your team is jQuery-fluent but XPath-averse, and the dominant cost is comprehension, not runtime.
• You are targeting PHP 5.6–7.x-era runtimes or an application already pinned to an old framework (the last tagged release is January 2016; expect deprecation noise and possible breakage on modern PHP 8.x, particularly around dynamic properties and DOMDocument behavior changes).
• Your use case is read-oriented and tolerant of imperfect HTML — note that DOMDocument's parser is not an HTML5-spec parser, so malformed or heavily-minified markup can produce surprising trees.
• You can vendor or fork it — with a single maintainer and no recent releases, the practical adoption model is "copy into src/ and own it," not "add to composer.json and forget."

Look elsewhere when:

• Symfony components are already in the stack. symfony/dom-crawler + symfony/css-selector is MIT-licensed, actively maintained, and covers the same selector vocabulary. This is the default answer for most teams.
• You need sustained security patching or a support commitment — an unmaintained parser fed untrusted HTML is an unbounded surface.
• The workload is high-volume or latency-sensitive; the jQuery-style fluent layer adds allocation overhead versus hand-written XPath, and you lose the ability to reason about complexity per query.
• You need HTML5-correct parsing — look at masterminds/html5 or a wrapper like DiDOM built on it.
• License hygiene matters for distributed software and your legal team will not accept LGPL without a review cycle you cannot afford on this timeline.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost convenience library that lets our PHP engineers write page-parsing code in a syntax most web developers already know. It is best framed as a prototyping accelerant, not a platform commitment. Two risks belong on the record: it is effectively unmaintained (no release since 2016, one author) and it carries an LGPL-2.1 license that needs legal sign-off before it ships inside distributed software. Recommendation: approve for internal tools and experiments, and default new production parsing work to Symfony's actively maintained equivalents so we do not inherit a migration project.

To engineering: pQuery gives you jQuery selectors and chaining over native DOMDocument — fast to read, fast to write, and a real fit for scraper and HTML-rewriting tasks. Understand the trade: it is a 2016-era dependency on modern PHP, it is not an HTML5 parser, and it will not get fixes. Treat it as a vendored internal utility rather than a Composer dependency you upgrade; if the code is customer-facing, in a security-sensitive path, or likely to outlive one quarter, use symfony/dom-crawler with css-selector instead and keep the same mental model.