Salvager Laravel Package

Product Decisions This Supports

• Feature feasibility for JS-rendered sources. If a roadmap item depends on reading pages that only render via JavaScript (SPAs, React/Vue storefronts, dashboards, infinite-scroll listings), this package lets us prototype that capability inside an existing Laravel app instead of standing up a separate browser-automation service. That shortens the "can we even get this data?" loop from weeks to days.
• Build vs. buy vs. adopt. It creates a real third option between "build a Playwright/Puppeteer microservice" and "buy a scraping API" (Browserless, ScrapingBee, Apify). For low-volume internal use cases, adopting a thin MIT wrapper is the cheapest path; the assessment forces an explicit decision rather than a default to custom infrastructure.
• Use-case triage. Reasonable fit: internal data ingestion (competitor pricing, catalog enrichment, content migration), link/asset auditing of JS-driven sites, scheduled snapshotting of a handful of pages, QA smoke checks on JS routes. Poor fit: anything customer-facing at scale, anything adversarial (anti-bot), anything needing proxies, geo-rotation, or high concurrency.
• Roadmap sequencing. Because it's tiny and unopinionated, it's a good spike dependency — validate the data is valuable and the crawl is stable before committing to a hardened architecture. It effectively de-risks the "is this dataset worth engineering for?" question.
• Sourcing/risk posture. With 7 stars and 0 dependents, this is a vendor-it-in-your-head dependency: assume we may need to fork or replace it. That itself is a product decision — do we accept maintenance ownership of ~a few files in exchange for avoiding a service?

When to Consider This Package

Consider it when all of these hold:

• You already run Laravel and want crawling to live in the same app, queue, and deployment model — no new service to operate.
• Target pages genuinely require JavaScript execution; static HTTP fetching (Guzzle, spatie/crawler, HTTP client + DOM parser) is insufficient.
• Volume is modest and batch-oriented: tens to low thousands of pages per run, tolerant of seconds-per-page latency, run via queued jobs.
• You can guarantee a Node + Playwright runtime in your containers/CI and are comfortable with that operational surface.
• You're willing to read, pin, and potentially fork a small codebase (MIT) — treat it as a starting point, not a supported platform.
• No anti-bot evasion requirement; you're crawling sites you own, have permission for, or public data with acceptable terms.

Look elsewhere when:

• Scale or concurrency matters — use a managed browser service (Browserless/ScrapingBee/Apify) or a dedicated horizontally-scaled Playwright worker.
• Pages are server-rendered — plain HTTP + parser is faster, cheaper, and far easier to operate; don't take on a browser runtime for nothing.
• You need robust crawling semantics (politeness, robots.txt, depth limits, deduplication, sitemaps) — spatie/crawler plus an HTTP client covers the static case; a mature crawler framework covers the rest.
• The goal is end-to-end testing — use Laravel Dusk or Playwright directly in CI; don't bend a scraper into a test runner.
• You need support, SLAs, or a security-reviewed dependency — a 7-star, single-maintainer package won't clear that bar. Also check Playwright/browser binary licensing and patching obligations in your environment.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel package that lets our existing application read web pages that require a real browser to render — the kind of modern site where a simple HTTP request returns an empty shell. It's a low-cost way to test whether a data-driven feature (pricing intelligence, catalog enrichment, content ingestion) is worth building, without funding a new service or a scraping vendor contract. The trade-off is maturity: it's an early-stage, single-maintainer project, so we'd pilot it behind an internal interface and keep a managed-service fallback priced and ready. Total downside if it doesn't work out: a few days of engineering, not a re-architecture.

For engineering: Thin wrapper over Playwright invoked from Laravel; the value is the integration, not novel technology. Adopt it only behind an internal PageFetcher-style contract so we can swap in an HTTP client for static pages and a hosted browser service for scale. Requirements: Node + Playwright in the runtime image, jobs isolated on their own queue with strict timeouts and memory limits, and a pinned version with the source read and vendored if necessary. Do not use it for high-concurrency or adversarial scraping, and do not let it become the de facto crawling framework — its scope is "render this page and give me the HTML."