sooyoos/extractor
A Laravel/PHP package that provides a simple, extensible extractor for pulling structured data from input using configurable rules. It keeps extraction logic reusable and organized, with a clean API that fits naturally into Laravel applications and is easy to extend for custom sources.
Architecture fit. As a Laravel/PHP package, the expected shape is a service provider plus an artisan command that walks app/, resources/views/, and routes/ to statically parse translation calls (__(), trans(), @lang, Lang::get) and emit or diff corresponding language files. That is a cross-cutting dev-tooling concern rather than a runtime concern, so if the package is well-behaved it should attach cleanly to the console layer without touching request handling, container bindings, or config outside its own namespace. The architectural value a TPM should care about is narrow and real: it converts translation-string drift from a manual, error-prone chore into a repeatable CI step, which is a genuine quality lever for any multi-locale product.
Integration feasibility. Nominally low effort — composer require, register the provider, run the command. The blocker is not effort but evidence. With zero stars, zero dependents, and a zero composite score, there is no signal whatsoever that this code runs on any currently supported PHP or Laravel version. The package name, authorship, and description style suggest it predates Laravel 5.4's package auto-discovery and quite possibly predates PHP 7. Nothing about the repository as presented demonstrates a working install on a modern framework.
Technical risk. High and concentrated in three places. First, compatibility risk: legacy packages typically break on modern PHP (removed each(), dynamic properties, create_function) and on Laravel's renamed translation helpers. Second, static-analysis risk: translation extraction is inherently a parsing problem, and naive implementations use regexes that miss concatenated keys, dynamic keys, and conditional strings while inventing false positives — which silently corrupts message catalogs. Third, provenance and supply-chain risk: an unvetted, unmaintained package executed in build tooling on developer machines and CI has full repository read access and can write files; that is a trust decision, not a convenience decision.
Key questions.
artisan?Stack fit. Reasonable on paper for a Laravel monolith or a modular Laravel app with per-module lang/ directories, provided the app is on a version the package tolerates. It is a poor fit for a distributed or microservice estate where translations are owned by a separate TMS — there the extraction step belongs in the localization pipeline, not in each service. It is also a poor fit if the team is not on Laravel at all, in which case the Symfony Translation extraction tooling is the direct equivalent.
Migration path. There is nothing to migrate from — this is greenfield tooling. The realistic path is: (1) a one-day timeboxed spike on a branch against the current Laravel version, pinned to the exact commit SHA; (2) run the extractor over a representative subset of the codebase and diff its output against the existing hand-maintained language files; (3) measure both false-positive and false-negative rates on that sample; (4) decide. If the spike fails to install or produces noisy output, the fallback is a ~200-line internal artisan command built on nikic/php-parser or Symfony's translation:extract, which is a small, owned, testable artifact — and for a package with this risk profile, that is a genuinely competitive option.
Compatibility. Must be verified against the exact PHP minor and Laravel major in production. Do not infer from the README. Check composer.json constraints directly and treat any * or absent constraint as a red flag. If the project is on Laravel 10/11 and the package declares support only up to 5.x, deprioritize immediately rather than attempting a fork.
Sequencing. Gate everything behind the spike. Sequence as: dependency audit and Composer constraint review → throwaway branch install → output-diff experiment → go/no-go decision → if go, wire as a developer-only require-dev dependency with a committed lockfile and a CI job that fails on catalog drift → only then extend to additional locales and modules. Never place it on the critical path of a release before the diff experiment has run at least twice against real branches.
Maintenance. Effectively zero upstream maintenance expected. The practical consequence is that the team owns the code whether or not it forked it: PHP or Laravel upgrades will eventually break it, and the fix will be local. Budget a standing few hours per framework upgrade cycle, and expect the true cost to be the fork, not the install. Pin to a commit SHA, vendor it internally, and document the fork point so the eventual replacement is a swap rather than an archaeology project.
Support. None. There is no issue-tracker velocity, no release cadence, and no one to escalate to. Do not let it into a compliance-sensitive path without a documented exception, since an unmaintained dependency with no dependents will fail most third-party risk reviews on sight.
Scaling. Extraction is a batch, offline concern running over the source tree — it does not scale with traffic, so there is no runtime scaling exposure. It does scale with codebase size and locale count, where naive implementations degrade toward slower runs and noisier output. It should not be invoked at request time or per-deploy on large repos; schedule it as a developer and CI step only.
Failure modes. Silent catalog corruption (extractor invents keys or drops existing ones and the diff is merged without review); false-negative drift, where keys added in code never surface and untranslated strings reach production in the fallback locale; framework-upgrade breakage discovered mid-release; and file-write side effects clobbering hand-edited language files. Mitigate with mandatory dry-run-and-diff, human review on every catalog change, a CI check comparing extracted against committed keys, and the language directory under version control so any destructive write is recoverable.
Ramp-up. Minimal in raw effort — a developer is productive in under an hour — but the ramp-up that matters is organizational trust-building. Expect a half-day of evaluation plus the spike, and treat the outcome as a deliberate build-versus-adopt call rather than an adoption. Given zero adoption signals, the honest recommendation to stakeholders is: evaluate for one day, expect to build the equivalent internally, and only adopt if the spike produces a clean install and a low-noise diff on real code.
How can I help you explore Laravel packages today?