Telefonkatalog Laravel Package

Product Decisions This Supports

• Feature / roadmap scoping: Confirms telefonkatalog is viable as a phone-number lookup and reverse-lookup capability for the Norwegian market (Gulesider, Opplysningen1890). This release is a maintenance-and-compatibility release, not a feature release — plan roadmap work around it, don't expect new capabilities from it.
• Framework upgrade decisions: Laravel 12 support lands here, and Laravel 10 is dropped. If your roadmap includes a Laravel 11/12 upgrade, this package is no longer a blocker. If you are staying on Laravel 10, the decision is explicit: pin ^1.2 and accept that the Gulesider scraper fix (and future fixes) will not reach you.
• Build vs. buy: This is a "buy/adopt-with-caveats" case, not a build case. The package is inherently scraping-based, so its core value is offloading the ongoing chore of tracking third-party website structure changes. v1.3.0 is direct evidence of that maintenance load — Gulesider changed its markup and the maintainer fixed it upstream. That is the value proposition working as intended, but it also means your reliability is coupled to the maintainer's responsiveness.
• UX and edge-case design: New tests for empty/non-existent search results plus improved handling of results missing phone numbers tell you the domain has messy, partial data. Product must design for "no match" and "match without phone number" states rather than assuming a clean happy path.
• Dependency hygiene as a gating criterion: Pest v3, Orchestra Testbench ^9.0|^10.0, a justfile, and removal of redundant dev dependencies signal active, current maintenance. Use this as a positive input when scoring the package against alternatives in a dependency review.
• Compliance triage: Nothing in this release changes the legal posture, but scraping personal data from Norwegian directory sites raises GDPR and terms-of-service questions that must be answered before this becomes a customer-facing or data-enrichment feature. Treat this as a decision blocker, not an implementation detail.

When to Consider This Package

Consider adoption when:

• You are on Laravel 11 or 12 (or upgrading to either) and need Norwegian phone/address lookup without building and maintaining scrapers yourself.
• Your use case tolerates best-effort, non-authoritative data — CRM enrichment, internal tooling, lead qualification, support-agent lookup — where a miss is inconvenient, not damaging.
• You can absorb breaking-change cadence: this release drops a Laravel major and rewrites a scraper's parsing strategy (JSON-LD replacing __NEXT_DATA__), i.e. output shape and coverage can shift between minor versions. Pin versions and test against fixtures.
• You have a caching and rate-limiting layer in your own application; scraping sources will not appreciate unbounded traffic.
• Legal/compliance has signed off on scraping public directories for your specific use case and jurisdiction.

Look elsewhere when:

• You need guaranteed uptime, SLAs, or contractual data provenance — use a licensed data provider or an official API instead.
• You are locked to Laravel 10 with no upgrade path; you would be adopting a package whose upstream fixes no longer reach you.
• Your product surfaces data to end users as authoritative (KYC, identity verification, fraud decisions). Scraper-derived data is stale and structurally fragile.
• You need coverage outside Norway, or need fields the scrapers do not expose.
• You cannot accept that a third-party site redesign can degrade your feature until an upstream patch ships.

How to Pitch It (Stakeholders)

To executives: This is a small, actively maintained open-source dependency that gives us Norwegian phone-number lookup without building or staffing a data-scraping effort ourselves. The latest release keeps us current with Laravel 11 and 12, so it removes a framework-upgrade blocker rather than adding one. The trade-off is that the data comes from scraping public directory sites, so it is best-effort and needs a legal review before it touches customer-facing or personal data. Cost is low; the risk is data reliability, not engineering effort.

To engineering: v1.3.0 adds Laravel 12 support and drops Laravel 10 — if you are on L10, pin ^1.2 and understand you will not receive the Gulesider fix. The Gulesider scraper now parses JSON-LD instead of __NEXT_DATA__, which is a meaningful behavioral change worth a regression test on your side even though it is not marked breaking. The package is now on Pest v3 with a justfile for local commands, and it added tests for empty/no-result and missing-phone-number cases, so the "no data" paths are covered. Standard hygiene applies: pin the version, wrap calls behind our own interface so we are not coupled to the package's API, cache aggressively, and add our own integration test with recorded fixtures so an upstream scraper change fails our CI rather than production.