Weave Code
Data Sourcery Bundle Laravel Package
netdudes/data-sourcery-bundle
A Symfony bundle that integrates Netdudes DataSourcery, helping you define, configure, and reuse data sources in your application. It provides bundle-level service wiring and integration helpers, plus a cleaner way to connect domain data to Symfony services with less boilerplate.
At a glance
Frequently asked questions about Data Sourcery Bundle
- Can I install netdudes/data-sourcery-bundle in a Laravel app?
- Not as a working dependency. It is a Symfony bundle built around Kernel::registerBundles(), a DependencyInjection extension class, a Configuration tree and compiler passes, and Laravel has no bundle loader — it consumes individual Symfony components, not HttpKernel's bundle system. A Composer require would install files without registering services or configuration, so treat this as a port project, not an install.
- What does Netdudes DataSourcery actually do?
- It defines reusable, configuration-driven data sources that keep query logic out of controllers and templates, with built-in filtering, sorting and pagination aimed at grids, APIs and admin interfaces. Sources are composed through the DI container as tagged services. Be aware this behavior is described from the package name and documentation only, so read the source before committing.
- What are the Composer requirements and PHP version constraints?
- The bundle pins symfony/framework-bundle and symfony/http-kernel constraints from the Symfony 2/3 era, which will very likely conflict with a modern Laravel or Symfony dependency graph. Run composer why-not against your target skeleton before anything else. If resolution fails or forces an EOL PHP runtime, that finding alone settles the build-versus-port question.
- Is netdudes/data-sourcery-bundle still maintained?
- No. The repository is archived, has roughly two stars and zero dependents. There is no security response process, no compatibility work for current PHP or Symfony releases, and no issue history to mine for known failure modes. The MIT license lets you fork it, but you own maintenance from day one.
- Does it work with Eloquent, or is it Doctrine-only?
- It is described as Doctrine-friendly, and Doctrine metadata assumptions do not translate to Eloquent. If the persistence layer is Doctrine-coupled, moving it to Laravel is a rewrite of that layer rather than a wrapper. Confirm this by reading the query classes before you estimate effort.
- How do I port a Symfony bundle like this to Laravel?
- Lift the framework-agnostic classes into a Laravel service provider, replacing the bundle extension and Configuration tree with a config/data-sourcery.php file and binding tagged services through the container. Symfony event-dispatcher priority ordering and %parameter% interpolation have no direct equivalent and must be rewritten by hand. Start with a one-to-two day source audit, and stop if the portable surface is only a few hundred lines.
- Is there a Laravel alternative for filtering, sorting and pagination?
- Yes. Query objects, repository patterns, or packages such as spatie/laravel-query-builder cover filtering, sorting and pagination on Eloquent without a port. Laravel's pipeline, queue and validation primitives usually replace a configuration-driven source layer. Reimplementing natively is often cheaper than adapting an archived Symfony bundle.
- How should I test data sources ported from this bundle?
- Extract the plain-PHP query logic behind an interface so it can be unit tested without a kernel or container. Then write integration tests that assert filtering, sorting and pagination behavior against a real database connection. The original bundle's test coverage is unverifiable, so add your own characterization tests if you fork it.
- Can I legally fork and vendor netdudes/data-sourcery-bundle?
- Yes. It is MIT licensed and the archive is public, so forking and vendoring the code into your own repository is legally clean. The constraint is engineering, not licensing: you inherit PHP and Symfony constraint updates, security triage and compatibility work. Assign an owner for that before you fork.
- Should I run a Symfony sidecar instead of porting this bundle?
- Almost never for a package with two stars and no dependents, because the operational overhead of a second service outweighs the value. A sidecar only makes sense if the bundle holds substantial logic that is genuinely hard to replicate. Establish the real line count first, since a few hundred lines should be rewritten natively rather than hosted.
Weaver
How can I help you explore Laravel packages today?