- Is fsi/datasource a Laravel package or a standalone PHP library?
- It is best treated as a standalone PHP component. Although the overview mentions a Laravel service provider and configuration, a technical review found no service provider, facade, config file, or publishable assets. It provides a driver abstraction plus condition objects for retrieving data from heterogeneous sources. In a Laravel app you will need to wire it up yourself, ideally behind your own DataSource interface so its types stay out of controllers.
- How do I install fsi/datasource with Composer in a Laravel application?
- You can install it with composer require fsi/datasource, but verify its composer.json constraints against your PHP and Laravel versions before committing. The last release was in February 2021, so dependency drift is the main risk on Laravel 10 or 11 with PHP 8.2 or 8.3. Run the install in a scratch branch, resolve against your real composer.lock, and run its test suite before planning production use.
- Does fsi/datasource support Laravel 10 and Laravel 11?
- There is no official Laravel 10 or 11 support statement, and the last release dates to early 2021. Its PHP and Symfony or PSR constraints are likely to conflict with modern Laravel stacks, so check composer.json first. If the constraints are stale but the extension points work, the expected path is to fork it internally, bump dependencies, and add CI rather than wait for upstream updates.
- What data sources can fsi/datasource read from?
- It exposes data through pluggable drivers, with the overview citing Eloquent models, arrays, and custom providers, plus built-in filtering, sorting, pagination, and column mapping. In practice the shipped drivers are likely Doctrine-oriented given the package's FSi Open and Symfony background. For Laravel you should expect to write at least one custom driver over Eloquent or the Query Builder. Confirm which non-Doctrine drivers ship before assuming out-of-the-box support.
- How does filtering and sorting work in fsi/datasource?
- Filtering and sorting are handled through specified condition objects that encapsulate what to fetch, while drivers encapsulate how to fetch it. That separation is clean, but you must verify the condition model is expressive enough for your real filters, including nested and/or logic, ranges, relations, pagination, and sorting. A mis-mapped condition produces a wrong result set rather than an error, so write golden-dataset comparison tests before trusting it.
- Can I use fsi/datasource to paginate and sort an Eloquent query?
- Pagination and sorting are listed features, but they are not turnkey for Eloquent because the package is not a native Laravel integration. You would write an adapter driver over Eloquent or the Query Builder and a mapper that turns your domain filters into the package's condition objects. For a single model this indirection buys little over Laravel's own query builder. The value appears when one uniform read interface must cover two or more dissimilar sources.
- Is fsi/datasource maintained and safe to use in production?
- Treat it as high risk: the last release was February 2021, it has roughly eight stars and no dependents, and provenance is a single organisation with no visible security-advisory process or LTS. Bus factor and dependency drift are the practical concerns, since any CVE or PHP minor-version break becomes your responsibility. The realistic approach is to fork it under an internal namespace, pin versions, add CI, and pilot it on one read-only, low-blast-radius endpoint with parity tests.
- What are good alternatives to fsi/datasource for Laravel tables and APIs?
- For a single database, Laravel's Eloquent and Query Builder already cover filtering, sorting, and pagination. Packages such as spatie/laravel-query-builder or Laravel DataTables wrappers handle the common table and API cases. Custom repository or query-object classes are another lightweight option. Consider fsi/datasource only when you genuinely need a uniform read port over multiple heterogeneous sources like MySQL plus a legacy ERP database plus a partner REST API.
- How do I integrate fsi/datasource with Laravel's service container?
- Plan a small adapter layer rather than expecting automatic discovery. Write a DataSourceServiceProvider that registers a driver registry, implement internal drivers over Eloquent or HTTP clients, and add a mapper translating your domain filter DTOs into the package's condition model. Expose your own DataSource interface to controllers and domain code so fsi/datasource remains an implementation detail. A one-to-two-day spike plus an adapter sprint is a realistic estimate before any production path.
- Is fsi/datasource tied to Doctrine or Symfony, and can I fork it?
- It comes from FSi Open, which is known for Symfony admin bundles, and its shipped drivers are likely Doctrine-oriented, so check whether any non-Doctrine driver exists and whether Symfony constraints conflict with Laravel. It is Composer-installable and MIT-licensed, so forking or vendoring under an internal namespace is legally and practically straightforward. If the spike passes but constraints are stale, fork to an internal package, bump PHP and dependencies, add CI and a composer.json replace, and assign an internal owner.