Data Sourcery Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for a data-source abstraction layer. This package is prior art for the "unify many heterogeneous data sources behind one read interface" problem — the feature that surfaces in reporting dashboards, admin-configurable data sources, and internal ETL tooling. Use it to size the problem and to sanity-check your interface design; do not use it as the implementation.
• Roadmap: whether to expose a pluggable "data source" concept to users. If anything on the roadmap resembles "let admins point us at their own data and query it uniformly," this is a worked example of the interface boundaries you'd need — source registration, normalization, query dispatch — worth an hour of a designer's or tech lead's time.
• Architecture hygiene: keep data access behind an internal contract. The existence and abandonment of packages like this is the argument for defining your own thin DataSource contract early, so swapping implementations later is a config change rather than a refactor. This is the single highest-leverage takeaway regardless of what you build.
• Framework-fit decision. Although catalogued here as a Laravel/PHP package, the -bundle suffix and netdudes namespace mark it as a Symfony bundle. Adopting it means paying real integration cost for a Symfony service-container idiom inside a Laravel app — a cost that must be weighed against simply writing the equivalent logic natively.
• Use cases it nominally serves: multi-source reporting, aggregation across internal systems, read-only "sourcery" over disparate backends. Note the metadata — 2 stars, 0 dependents, archived — there is no evidence of production use anywhere, so it informs decisions but must not be the basis of one.

Caveat: this is inferred from the package name, bundle conventions, and repository metadata. Nobody has read the code in this assessment — the first task in any spike is a 30-minute source review to confirm scope.

When to Consider This Package

Consider it only as reading material. Concretely:

• You are writing a design doc for an internal data-source abstraction and want a worked example of the interface shape. Budget 1–2 hours. Timebox it.
• You need prior art to argue against a homegrown abstraction — or to justify the one you're building.
• You have a genuine, narrow need the code happens to solve, and you are willing to fork it under MIT, vendor it into your own repo, and assign a named internal owner. The permissive license is the one unambiguously green flag here.

Look elsewhere — which is the default — when:

• You need a maintained dependency. It is archived: no security patches, no PHP or Symfony compatibility work, no upstream fixes. That is a supply-chain risk you cannot mitigate without forking.
• You need community support or proof of fitness. Zero dependents and two stars mean no battle-testing, no Stack Overflow corpus, and no issue history to mine for known failure modes.
• You are on Laravel. Take the framework-native path: Eloquent/query builder, a maintained query-filtering package, or a maintained Laravel-native reporting/data-source library. Budget real time for adapting a Symfony bundle's service wiring, config semantics, and event model.
• The abstraction is load-bearing. Anything on a revenue or compliance path needs a maintainer with a support commitment. This has none.
• You need performance guarantees. No benchmarks, no users, no evidence.

How to Pitch It (Stakeholders)

Executive summary — recommendation: no-go for adoption; go for a short teardown.

We evaluated netdudes/data-sourcery-bundle (MIT) as a possible foundation for our data-source abstraction work. It is archived, has two stars and zero dependents, and is a Symfony bundle rather than a Laravel package. It has no maintainer, no security-update path, and no evidence of production use. Adopting it would transfer an unbounded maintenance obligation onto our team while saving, at most, a few days of design work.

What we recommend instead: a one-to-two-hour engineering spike to read the source and extract interface and naming ideas for our own thin DataSource contract. Cost is negligible; the output is a design input, not a dependency. If a specific piece proves genuinely valuable, we fork it into our repo under MIT with a named owner — a decision we would bring back for approval.

For engineering: treat this as a reference implementation, not a library. Do not add it to composer.json. If the abstraction proves compelling, the deliverable is a one-page comparison against the framework-native options we'd otherwise use, plus a recommendation on whether to build our own contract now or defer until a second consumer appears.

Risk if we ignore this and hand-roll anyway: we rebuild a well-understood abstraction badly and late. The mitigation is cheap — read the prior art before designing, and keep the interface small enough to swap.