awcodes/hydro
Hydro is a lightweight Laravel/PHP package by awcodes that offers practical helpers for common application tasks. It emphasizes a clean, expressive API that drops into existing projects with minimal setup. Visit the repository for installation steps and usage examples.
Architecture fit. Hydro is a build-time developer CLI, not a runtime library. It belongs in Composer's global layer or a require-dev scope of a plugin-development repo, and it scaffolds a Filament plugin package locally instead of cloning Filament's GitHub Plugin Skeleton. Architectural blast radius is confined to developer workstations and CI scaffolding jobs — no service provider in deployed apps, no request path, schema, queue, or storage footprint. For a TPM this means the package never appears on a production risk register, and the entire evaluation collapses to one question: is our Filament plugin cadence high enough that a repeated manual scaffold step is worth optimizing? If the roadmap contains zero or one plugin, Hydro supports no decision at all; if a platform team or agency stands up plugins monthly, it removes a small but recurring tax.
Integration feasibility. Technically feasible as a globally installed dev tool or pinned require-dev in a package-development repo, but the evidence base is thin and dated. Thirteen stars, zero dependents, a single maintainer, and a last release in March 2023 give no signal about compatibility with current Filament, Laravel, or PHP — and March 2023 predates Filament v3 plugin conventions. A further red flag for a TPM is documentation integrity: the package's own description describes an image-watermarking library while the tool actually scaffolds plugins. Inconsistent self-documentation on a low-adoption package is a direct proxy for the support burden you'd inherit. Treat any integration as a time-boxed spike, not a committed dependency.
Technical risk. Risks are asymmetric and mostly low-severity. Runtime and security risk are negligible because the tool should never ship to production. Delivery risk is moderate: stale generated conventions, CLI breakage against newer PHP, broken Composer constraints, and onboarding confusion if internal docs assume the GitHub skeleton. Supply-chain risk from adding an unmaintained dev dependency is non-trivial but mitigable through lockfiles, an internal Composer mirror, and fork readiness. Bus factor is one; abandonment is the base case. The realistic PM framing is replicate in-house or adopt as a reference implementation — not "buy a strategic dependency."
Key questions. Which Filament, Laravel, and PHP versions do the stubs actually target? What exactly does the generator emit, and does it match internal naming, namespace, and test conventions? Is the license compatible with forking and vendoring? Does it require network access or GitHub tokens? Who owns it internally, and is the escalation path upstream or the fork? Can we pin and mirror it? What is the exit cost if Filament changes plugin conventions again? What happens if a generated scaffold fails CI — is the fallback documented?
Stack fit. Strong fit only for Laravel teams actively building and maintaining Filament plugins — a platform team owning an internal plugin suite, or an agency repeatedly scaffolding client plugins. It is irrelevant for non-Laravel stacks and low-value for teams creating a plugin once or twice a year. Because it installs as a global CLI, an individual engineer can trial it without touching any project's dependency graph, which makes a zero-blast-radius pilot cheap to authorize.
Migration path. Do not retire the existing GitHub Plugin Skeleton workflow. Run a parallel pilot: install Hydro in a sandbox, generate one representative plugin, push it through existing lint, static analysis, test, and CI pipelines, and diff the output against the skeleton-based baseline. If the generated package is equivalent or better and CI passes, document Hydro as the preferred local path while keeping the skeleton as the supported fallback. If it diverges, record the specific gap and revisit only if upstream revives or Filament ships native scaffolding.
Compatibility. Validate explicitly against the current PHP, Laravel, and Filament versions in the supported matrix; do not assume 2023 stubs are current. Expect to pin the tool version and possibly apply a small fork patch to the stubs. Confirm the generated composer.json, service provider, test harness (Testbench/Orchestra if present), and README conform to internal standards. Run the pilot in CI, not only locally, so version-resolution and constraint problems surface before adoption.
Sequencing.
packages/ directory wired via a Composer path repository.Maintenance. Low steady-state load if pinned, but this is effectively an unmaintained dependency. The realistic operating model is "we own it if we adopt it": plan for a fork, a minimal patch cadence, and compatibility checks each Filament major cycle. Budget a small fraction of one engineer's time per major release, plus the occasional fix when stubs drift.
Support. No vendor support and no escalation path upstream. Community-only, single maintainer, low issue volume, inconsistent self-documentation. Internal documentation and a named owner are mandatory. The tool must not become tribal knowledge — if onboarding docs say "run hydro" with no fallback, new hires are blocked the moment it breaks.
Scaling. The command itself scales trivially: per-developer, no runtime footprint. The scaling concern is consistency. As headcount grows, generated plugin structure must match internal standards or the platform team inherits cleanup work. Standardize via a documented template, CI checks on generated packages, and a single canonical source of truth for scaffolding.
Failure modes. Most likely, in rough order: incompatibility with a newer Filament or PHP version; command breakage or stale prompts; generated code diverging from current conventions; abandonment or repository disappearance; supply-chain compromise of a dev dependency (possible but contained by lockfiles and mirrors). A secondary failure is documentation rot — engineers using the wrong scaffolding path, or a scaffold silently producing outdated package structure. Least likely and lowest impact: production outage, because the tool should never ship to production.
Ramp-up. For a Laravel/Filament developer, well under a day to learn the commands and understand the generated structure. For the TPM or platform owner, the ramp is mostly governance: writing the adoption criteria, defining the pinning and mirroring policy, naming an owner, documenting the fallback path, and setting the re-evaluation trigger at each Filament major release. Treat the effort as a time-boxed spike measured in days, not weeks — and if plugin creation isn't a recurring cadence, spend that box on an internal script instead and skip the dependency entirely.
How can I help you explore Laravel packages today?