Frujax Bundle Laravel Package

Product Decisions This Supports

• Serialization / API output strategy (reference architecture, not adoption). Frujax sits in the "turn domain objects into stable JSON envelopes" space — the same decision surface as Fractal, API Platform, Symfony Serializer groups, or hand-rolled transformers. Reviewing it is useful mainly as a catalogue of how one team answered that question in 2018: what they normalized, what they left to the caller, and where the envelope/metadata logic lived.
• Build vs. buy vs. vendor. The package is archived, unmaintained, and has zero dependents and zero stars. The realistic decision this supports is "do we fork or vendor a dormant serializer, or do we write ~200 lines ourselves?" — and the answer is almost always the latter, because the dependency surface (Symfony version coupling, PHP version ceiling) will cost more than the code is worth.
• Ecosystem mismatch check. This is a Symfony bundle, not a Laravel package. If a roadmap item assumes "there's a Laravel package for this," this repo is evidence to the contrary and should correct that assumption early, before it reaches an estimate.
• Legacy inventory / due diligence. If a codebase or an acquisition target already depends on Ruwork bundles, this flags a maintenance liability: pinned Symfony major, no security response, no upstream. That's a remediation line item, not a feature line item.
• Not a roadmap input otherwise. There is no feature, growth, or platform decision where adopting a 2018 archived bundle with no users is the recommended path.

When to Consider This Package

Consider only as reading material, when:

• You are designing a JSON serialization layer and want to see a compact, real-world Symfony bundle layout — service definitions, DI extension, configuration tree — as a structural template.
• You are doing due diligence on an existing Ruwork-based stack and need to understand what this bundle contributed.
• You need the concept (a bundle that owns response shaping) and will reimplement it against the current framework version.

Do not consider it when any of the following is true — which, in practice, is nearly always:

• You are on Laravel. This is a Symfony bundle; there is no Laravel service provider, no facade, no config publish. Bridging it costs more than writing the equivalent.
• You need a supported dependency. Last release 2018-07-04, archived, MIT, zero dependents. No security patches, no PHP 8.x/Symfony 6–7 compatibility path, no maintainer to escalate to.
• You need community support. Zero stars, zero dependents means zero Stack Overflow answers, zero blog posts, zero people who have debugged your exact error.
• You are choosing between this and a maintained option. Symfony Serializer, API Platform, Fractal, or league/fractal wrappers all have active maintenance, docs, and hiring pools.
• You require test coverage or CI signals before adding a dependency — none are evidenced here.

The opportunity score (5.87) is best read as whitespace in the category, not as a signal about this artifact. The category gap is real; this specific package is not the answer to it.

How to Pitch It (Stakeholders)

For executives (one line): We evaluated a candidate JSON-serialization component; it is an archived 2018 Symfony bundle with no users and no maintenance, so we are not adopting it — we'll use a maintained alternative or a small in-house module, and the only cost is a few days of engineering, not a platform bet.

For engineering leads: This is a zero-adoption, archived Symfony bundle last released in 2018. It is not a Laravel package despite the framing, so there's an integration tax on top of the maintenance tax. Recommendation: do not add as a dependency. Spend at most half a day skimming its bundle structure if we're designing our own serializer layer; otherwise close the ticket. If it already appears in our dependency graph, treat it as tech debt — pin, isolate behind an interface, and schedule replacement.

Framing for the "why not": The relevant risk isn't that the code is bad — it's that the code is unowned. An unmaintained serializer sits directly in the request/response path, which means any incompatibility becomes an outage in our API surface, with no upstream to call.

What we'd do instead: pick a maintained serializer (Symfony Serializer with groups, or API Platform if we want the full resource layer), or write a thin transformer layer we control — typically a few hundred lines, fully tested, and compatible with the framework versions we actually run.