Sic Bundle Laravel Package

Technical Evaluation

Architecture fit — fundamental mismatch, unchanged by v6.0.0. gepur-it/sic-bundle is still a Symfony bundle: the Bundle suffix, the gepur-it portfolio, and the release note's own framing ("upd php 8 and symfony 5 in composer") all confirm the target framework. Laravel has no bundle registration mechanism, no Bundle class, no DependencyInjection\Extension, and does not autodiscover Resources/config/services.yaml. The package cannot be installed into a Laravel application and "just work." The functional intent ("Single Instance Console Command") remains a per-command mutex/overlap guard — a 100–200 LOC concern, not an architectural component.

What v6.0.0 actually changes — a composer constraint bump, nothing more. The release note describes exactly two edits: a PHP 8 floor and a Symfony 5 constraint. There is no feature work, no changelog of behavioral changes, no security fix, no test/CI signal. Critically, the Symfony bump stops at 5, and that specific choice is the decisive fact for this evaluation.

Integration feasibility — still low, and now worse-constrained than the prior assessment implied. The prior assessment predicted Composer resolution failure against modern Symfony. v6.0.0 confirms it from the other direction: pinning to Symfony 5 means the package can only co-resolve with Laravel 8 or earlier (Laravel 9 requires Symfony ^6.0; Laravel 10 ^6.2; Laravel 11/12 ^7.0). Laravel 8 has been end-of-life since January 2023. So the release moves the package from "will not resolve against a supported Laravel" to "resolves only against an unsupported Laravel." That is not progress toward adoptability. Separately, Symfony 5.4 is at or past the end of its security-support window, so the package's own transitive dependency line is unpatched — a material fact if anyone were to install it.

Partial correction to the prior assessment: the claims "no PHP 8.2/8.3/8.4 declared support" and "last release 2021-04-19, ~5 years stale" are now outdated. PHP 8 is declared, and the project showed a pulse. Everything else in the risk profile — 1 star, 0 dependents, score 0.005, no third-party consumption, no CVE coverage, no ecosystem pressure — is carried forward unchanged; the review data supplied with this release is empty, so those adoption signals must be treated as unverified rather than improved.

Technical risk — high, marginally re-characterized.

• Maintenance signal is weak, not restored. A single-commit constraint bump after a five-year gap is a heartbeat, not a maintenance program. There is no evidence of CI, a test suite, a supported-version policy, an issue triage cadence, or a security-response process. One release does not create a bus factor above one.
• Target stack is EOL on both axes. Symfony 5 (security support expired) plus Laravel ≤8 (EOL) means any adoption starts on an unsupported foundation and inherits two unpatched dependency trees.
• Locking semantics remain unknown and unreviewed. Fail-open vs. fail-closed, PID-awareness, TTL presence, and per-argument key scoping all materially change correctness, and none is addressed by a composer edit. A stale-lock bug in a cron guard is a silent failure — jobs stop running and nobody is paged.
• Major-version tag with no migration note. v6.0.0 signals a breaking constraint change; the note explains neither what broke nor who is affected. For a package with zero dependents this is low-consequence but confirms the absence of release discipline.

Key questions for the maintainer (or for a fork's design doc):

1. Why Symfony 5 rather than 6/7 — is the code actually incompatible with modern Symfony Console, and if so, what is the blocker?
2. Is there a stated supported-version matrix (PHP × Symfony), and is it tested in CI?
3. What is the lock backend — filesystem, symfony/lock, database, or PID file?
4. Is the lock released on SIGTERM/SIGKILL, or does a crash leave a permanent stale lock?
5. Is there a TTL/expiry, and what happens if a command's runtime exceeds it (double-run)?
6. Can the lock be scoped per argument (per-tenant, per-queue), or is it global per command name?
7. Does it fail closed or open if the lock store is unreachable?
8. Does the listener interact safely with pcntl_fork, daemons, and schedule:run overlap?

Integration Approach

Stack fit: do not install. Block the dependency in Composer review. The new release does not change the verdict — it supplies the concrete evidence for it. Confirm with composer why-not gepur-it/sic-bundle, which should now fail on the Symfony 5 constraint against any Laravel ≥9 lockfile.

Migration path — build, don't buy (unchanged):

1. For scheduled commands, use the native scheduler middleware: ->withoutOverlapping(expiresAt: 1440).
2. For manually invoked artisan commands, attach Illuminate\Console\Middleware\WithoutOverlapping to the command class.
3. If argument-scoped locking is a real requirement, implement it with Cache::lock("cmd:{$name}:{$tenantId}") and ->block(0) / ->get(), with a TTL derived from the command's p99 runtime and a documented behavior when the lock is held.
4. The v6.0.0 bump does not create a new reason to fork. A fork would now carry the added burden of upgrading the Symfony constraint to 6/7 — work that, if worth doing at all, is worth doing as 150 lines of in-house Laravel code against Cache::lock().

Compatibility checkpoints before any adoption decision:

• Run composer why-not against the current lockfile; record the Symfony conflict as the formal rejection rationale.
• Verify the target environment's lock store. File locks are invalid on ephemeral container filesystems and under multi-node ECS/Kubernetes; a shared Redis or database store is mandatory.
• Confirm the PHP 8 floor's exact version (^8.0 vs ^8.2); a floor of 8.0 keeps deprecated-syntax risk alive on 8.3/8.4.

Sequencing:

1. Week 1 — Inventory: enumerate long-running and cron-invoked artisan commands; separate those genuinely needing single-instance guarantees from those already idempotent. This may eliminate the need for any new code.
2. Week 1 — Baseline: apply native withoutOverlapping to the shortlist with a conservative expiresAt and alerting on skipped runs.
3. Week 2 — Multi-node validation: confirm the scheduler sits behind a shared lock store; verify behavior when a node dies mid-command.
4. Week 3 — Gap analysis: if argument-scoped locking remains unmet, write it in-house with tests. Skip the fork unless an audit finds a genuinely superior stale-lock recovery strategy — v6.0.0 offers no such evidence.

Operational Impact

Maintenance: a single constraint-bump release after a five-year gap is a net-positive signal, but it does not constitute upstream maintenance. Adopting still transfers the maintenance burden to the adopting team on day one, and now with an extra liability: the package targets Symfony 5, so the adopter inherits responsibility for an unpatched framework line as well as for the package. Bus factor remains one agency; zero dependents means breakage surfaces only in your environment.

Support: no documentation beyond a README, no issue triage, no security response process, and now a major-version tag with a one-line, lowercase release note. Any incident is internal debugging against unfamiliar 2021-era code — slower than reading an in-house implementation.

Scaling: file-based locking is the default failure mode for packages of this vintage and is incompatible with horizontally scaled or containerized deployments — ephemeral filesystems give each replica its own lock namespace, so the guard silently does nothing. Redis-backed locks introduce a second failure mode: lock loss on failover permits concurrent execution of the very command the guard serializes. Neither is observable without instrumentation.

Failure modes to design around:

• Silent suppression (highest severity): a stale lock after SIGKILL means the cron job never runs again — missing data, not errors. Mitigate with TTLs, a lock-age metric, and an alert when a command has not started within its expected window.
• TTL overrun / double-run: a command exceeding the lock TTL permits a second concurrent instance, defeating the package's purpose.
• Lock store unavailability: fail-open/fail-closed semantics still unpinned; must be determined and alerted either way.
• Fork/daemon unsafety: inherited file descriptors or PID files behave unpredictably under pcntl_fork and queue workers.
• Dependency decay (new): with Symfony 5 past security support, any installed copy accrues unpatched transitive risk without upstream remediation.

Ramp-up: trivial to learn (one concept, one behavior) and equally trivial to replace. Team effort is better spent on observability — lock acquisition/release events, held-lock duration, and a "job did not run" alert — because the guard's value depends entirely on detecting when it misfires. Budget hours there, not on integrating an unmaintained Symfony bundle into a Laravel application.

Recommendation: reject — unchanged. v6.0.0 is a composer constraint bump that modernizes the PHP floor while pinning the framework floor to an EOL Symfony/Laravel generation; it addresses none of the architectural, semantic, or operational concerns that drove the original assessment. Use Laravel's native WithoutOverlapping middleware and build argument-scoped locking in-house if a real requirement exists. Revisit sic-bundle only as a design reference during the audit, not as a runtime dependency.