Edt Extra Laravel Package

Product Decisions This Supports

• Build vs. buy for tabular-data plumbing. edt-extra belongs to the DEMOS Europe edt-* family, an academic/civic-tech toolkit for defining and serving tabular datasets from a Laravel application. If a roadmap item is "let users browse, filter, and export structured datasets," this package is a candidate accelerant rather than a from-scratch build — but it is an add-on to a core edt package, not a standalone solution, so the real build-vs-buy question is whether to adopt the whole family.
• Roadmap scoping for data-centric products. Relevant to open-data portals, research data catalogues, indicator/scoreboard tools, and EU-funded civic-tech deliverables where the data model is "rows and columns with metadata" rather than rich domain entities.
• Feature decisions around dataset exposure. Supports decisions on how much query/filter/export capability to hand to end users versus hard-coding views, and whether metadata + dataset concerns live in one abstraction or two.
• Reference implementation, not a platform bet. With ~1 star, 0 dependents, and a low opportunity score, this is best treated as prior art — a worked example of tabular data modelling in Laravel that inform architecture decisions even if never installed.
• Negative signal worth recording. The package's adoption profile argues against it being load-bearing for anything with a support obligation; documenting that now prevents a future "why didn't we just use this?" conversation.

When to Consider This Package

Consider it when all of the following hold:

• You are already in, or deliberately evaluating, the DEMOS Europe edt ecosystem — the core dataset/query package is a prerequisite, and edt-extra only makes sense as a companion layer.
• Your product is a Laravel application whose primary artefact is tabular data — datasets, indicators, statistical tables — with a need for filtering, metadata, and export.
• You are in a research, public-sector, or grant-funded context where the DEMOS conventions (schema shapes, terminology, EU project assumptions) map onto your requirements rather than fighting them.
• Vendor risk is tolerable: MIT-licensed, small surface, and your team can read, fork, and own the code. Budget for that ownership explicitly.
• You can timebox a spike — one to two days wiring it against a real dataset — and walk away if the fit is poor.

Look elsewhere when:

• You need maintenance guarantees, security response, or an active community. One star and zero dependents means no ecosystem, no Stack Overflow answers, no third-party bug reports.
• Your data needs are general-purpose — imports/exports, admin CRUD tables, reporting. Mature options (Laravel Excel, Filament/Spatie table tooling, or plain Eloquent + database views) will be better supported and better documented.
• You are not on the edt core package; pulling in a transitive family of low-adoption dependencies for a peripheral feature is a poor trade.
• You need Laravel-version currency — verify supported framework versions before committing; a single-maintainer research package often lags.

Due diligence before adoption: last commit date, test coverage, whether edt core is pinned to an old Laravel major, and how much DEMOS-specific domain vocabulary leaks into your schema.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed Laravel add-on from the DEMOS Europe research stack that handles tabular datasets — defining them, querying them, exposing them. The strategic case is cheap optionality: no licence cost, no lock-in, and if it fits we skip weeks of dataset plumbing. The honest caveat is that it has essentially no external adoption, so it should be pitched as an accelerator we fork and own, never as a foundation we depend on. Recommended ask: a short, timeboxed evaluation, not a commitment.

For engineering: Treat it as a reference implementation first and a dependency second. The interesting content is how it separates dataset definition from query/serialisation concerns — that pattern is reusable even if the code isn't. If we do adopt, we own it: assume we are the maintainers, pin the version, vendor or fork it, and confirm the edt core dependency and Laravel version support before any integration work. If it duplicates an abstraction we already have, the honest answer is probably no.

Bottom line: low-risk to evaluate, low-cost to abandon, low-signal as a signal. Worth a spike only if tabular dataset management is genuinely on the near-term roadmap.