Filanitics Laravel Package

Getting Started

Do not install this package. The only published release (v1.0.0, 2025-04-11) is a self-described placeholder: "This is just a husk from the original, no need to install from here." There is no service provider, no widgets, no config to publish, and no usable API. Any "getting started" that begins with composer require sepremex/filanitics is starting in the wrong place.

What to do instead, in order:

1. Check whether it is already in your project. Before anything else, confirm it is not quietly present:

   composer show sepremex/filanitics
   grep -n "sepremex/filanitics" composer.json composer.lock
   composer why sepremex/filanitics   # identifies direct vs. transitive requirer
   

2. Find the original upstream. The description (Filament widgets for stats, charts, trends, date-range filtering, configurable metrics) describes a real feature set, so an original package or an internal equivalent almost certainly exists. The release note is a pointer, not a deliverable — trace it before doing anything else.
3. Evaluate the real candidate. Only after you have the canonical source (or a maintained Filament analytics alternative) do you run a normal spike: install it in a throwaway Filament panel, publish the config, wire one widget to a real Eloquent model, and confirm it renders an actual number.

First legitimate use case: provenance and dependency audit — not feature work. If someone on your team surfaced this package, the useful first step is to determine whether it is a mirror, a fork, a placeholder, or a name collision, and to record the outcome in your dependency register so the next engineer does not repeat the investigation.

If you need Filament analytics today: look at maintained Filament analytics/widget packages or build a thin internal widget set. A StatsOverview widget plus a ChartWidget backed by your own aggregate query is a few dozen lines — often less work than vetting a dependency.

Implementation Patterns

There are no usage patterns to document because there is no implementation to pattern against. The patterns below are the substitutes — what a developer actually does when this package appears in a candidate list or a lockfile.

Pattern: the denylist entry (recommended default). Add the package to your dependency policy so it fails fast rather than being silently resolved by a future composer require:

{
  "conflict": {
    "sepremex/filanitics": "*"
  }
}

A conflict constraint in the root composer.json is cheap, reversible, and blocks accidental adoption across the whole monorepo.

Pattern: transitive removal. If composer why shows an intermediate package pulling it in, do not vendor or patch around it. Raise it with that package's maintainer, and if the dependency is truly inert, use Composer's replace/override mechanism deliberately and with a comment in the PR — not as a permanent workaround.

Pattern: repoint to the canonical package. If the original upstream is resolvable and maintained, the migration is a composer.json edit plus a search-and-replace of the namespace. Expect API divergence — the husk makes no compatibility promise with the original, despite the v1.0.0 version number.

Pattern: build the widget instead. For a small dashboard need, the real-world integration in a Filament panel looks like this — a stats overview widget bound to whatever model you actually care about:

use Filament\Widgets\StatsOverviewWidget;
use Filament\Widgets\StatsOverviewWidget\Stat;

class SignupsOverview extends StatsOverviewWidget
{
    protected function getStats(): array
    {
        return [
            Stat::make('Signups (30d)', User::where('created_at', '>=', now()->subDays(30))->count()),
            Stat::make('Revenue (30d)', Order::where('paid_at', '>=', now()->subDays(30))->sum('total')),
        ];
    }
}

Register it on the panel, add a date-range filter via a widget property bound to a form field, and you have the core of the advertised feature set with zero supply-chain exposure. This is the pragmatic "buy vs. build" answer here: build, because there is nothing to buy.

Pattern: document the decision. Record in your dependency register: candidate, date, release inspected, the verbatim release note, outcome (excluded), and the alternative chosen. This is the single highest-value artifact this package will ever produce for your team.

Gotchas and Tips

• The version number is a trap. v1.0.0 and a 2025-04-11 release date read as "new but stable." They are not. A 1.0.0 here means "first and only release," not "API-stable." Do not let a constraint like ^1.0 create false confidence in review tooling.
• "Husk from the original" means unknown deltas. You cannot reason about what was stripped or left behind. Do not assume behavioral parity with the upstream package just because the name and description match — the description may have been copied wholesale.
• Namespace-takeover risk is the real hazard. An installable package name that the publisher disclaims is a future-hijack target. If the name is later re-registered, composer update will happily resolve unreviewed code. Block it now, while it costs nothing.
• Cold-cache build failure. If it is already locked anywhere, dist deletion or tag removal upstream will break composer install on a fresh machine — with no fix available from the publisher. Rebuild without cache in CI to surface this early rather than during an incident.
• Zero onboarding cost is a mirage. No README usage section, no tests, no examples. A new engineer will spend time discovering why it cannot be used, not how to use it — mitigate by writing the rationale down.
• Check the Packagist abandoned flag. If the package is not marked abandoned, consider requesting it, and watch for ownership transfer on the Packagist page. A change of maintainer identity is a strong signal to treat the name as untrusted.
• Extension points: none. The description advertises "extensible with custom models and queries" and "publishable config" — treat all of it as unverified marketing copy until you have an artifact whose publisher stands behind it. Do not design around a config schema you cannot read.
• The one thing worth keeping from this release note: the maintainer's honesty. It is a working example of why a do-not-use notice in a release channel is better than a silently empty package — cite it when arguing for provenance checks in your dependency review process.