Enqueue Fs Laravel Package

Product Decisions This Supports

• Brokerless async processing for constrained deployments. This package lets the filesystem act as a message transport under the enqueue abstraction. The product decision it unlocks is whether to ship background jobs/event handling in environments where provisioning Redis, RabbitMQ, or SQS is impossible or undesirable: shared hosting, single-VM self-hosted installs, on-prem appliances, air-gapped or regulated networks, and demo/on-prem trials.
• Build vs. buy for a queue driver. The scope is narrow (one transport adapter). The real decision is "adopt the enqueue abstraction + a cheap transport" vs. "write ~100–200 lines against Laravel's database queue driver" vs. "commit to a managed broker." At 0 stars / 0 dependents, this should be evaluated as a starting point or reference implementation, not as an ecosystem dependency.
• Roadmap sequencing for event-driven features. It supports a phased plan: ship outbox/job semantics on a filesystem transport for v1 pilots, keep the enqueue interface as the seam, and swap in Redis/SQS/AMQP when volume or multi-node requirements arrive — deferring the broker selection decision without blocking feature delivery.
• Local development and CI parity. A real decision for engineering productivity: whether dev/CI should exercise genuine queue semantics (serialization, delayed delivery, retries, failure paths) instead of sync, at zero infrastructure cost.
• Use cases worth prototyping: delayed/low-volume scheduled jobs, webhook and email outboxes, import/export pipelines, nightly batch fan-out, and migration of legacy cron-over-directory workflows into a typed producer/consumer model.
• Explicitly not a scaling decision. Adopting this should be recorded as a constraint (single-node, moderate throughput), not as a queue strategy. It buys time and optionality; it does not buy throughput, HA, or observability.

When to Consider This Package

Consider it when most of these are true:

• You already use (or are willing to standardize on) enqueue/enqueue; this is only a transport, so it carries the abstraction's API and learning curve with it.
• Target deployments are single-node, low-to-moderate volume, with jobs that are idempotent and tolerant of seconds-to-minutes latency.
• Infrastructure genuinely cannot host a broker — shared hosting, customer-managed on-prem, offline/air-gapped, edge or appliance installs, or ephemeral CI.
• You want dev/test to exercise real async semantics without running Redis in every developer's environment.
• The team is comfortable owning the code: plan to vendor/fork it, pin the version, and wrap it behind your own interface so the transport is replaceable.
• Throughput, ordering, and delivery guarantees are documented as "best effort, filesystem-dependent" and accepted by the business.
• The Oct 2024 release, MIT license, and the package's recent dependency consolidation (0.10.21 replaced enqueue/dsn with micro-module/dsn) are acceptable provenance for an internal utility — see the dependency note below before you pin.

Dependency note (0.10.21): the release swaps the upstream enqueue/dsn component for the author's own micro-module/dsn. Functionally this should be a no-op for DSN parsing, but for a due-diligence review it matters in two ways. First, it adds a second single-maintainer package to your transitive dependency graph, so your pin/vendor policy must cover micro-module/dsn as well as this package. Second, it signals the package is drifting from a pure "thin adapter over upstream enqueue" posture toward the author's own micro-module/* line — meaning future releases may increasingly depend on that family rather than on upstream enqueue. Neither is disqualifying for an internal utility, but confirm the DSN grammar your configuration uses (file:// paths, options, query strings) still parses identically after the swap, and lock both packages to the same pinned set. Treat the release as a routine maintenance change, not a feature, and re-run your spike's config/connection tests rather than re-running the full evaluation.

Look elsewhere when any of these are true:

• Multi-node or autoscaled workers, horizontal consumers, or shared storage across hosts (file locking and NFS semantics become a correctness and performance hazard).
• You need SLAs on latency/throughput, strict ordering, exactly-once or at-least-once with durable acks, dead-letter handling, or replay at scale.
• Operational visibility matters — queue depth dashboards, alerting on backlog, and drain tooling are not what a transport shim provides.
• You are on Laravel and simply want a queue: the built-in database driver (or Redis/SQS) is maintained by the framework, has first-class Horizon/console tooling, and removes an unmaintained dependency from your supply chain.
• You need vendor support, security patching commitments, or a deprecation policy — 0 stars and 0 dependents means no field validation and no community backstop.
• Your jobs are latency-sensitive, high-frequency, or carry large payloads where filesystem I/O and per-message file overhead dominate.

Adoption gate before committing: a one-to-two day spike covering (1) a throughput benchmark at your expected peak, (2) failure-mode tests — partial writes, interrupted consumers, corrupt/unreadable message files, lock contention, disk-full behavior, (3) a documented fallback path to the database driver, and (4) an owner on the team for the vendored copy. With 0.10.21, add (5) a DSN round-trip test against micro-module/dsn using exactly the connection strings you intend to ship.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed utility that lets our application run background jobs using ordinary disk storage instead of a paid or self-hosted message broker. It is not a platform bet — it is a low-cost option that keeps us deployable in customer environments (on-prem, shared hosting, restricted networks) where we currently cannot install queue infrastructure. The investment is a short engineering spike, not a procurement cycle; the risk is dependency on a tiny, single-maintainer package, which we mitigate by pinning and wrapping it behind our own interface so it can be swapped for Redis, SQS, or the database queue with a config change. The latest release (0.10.21) is housekeeping — it repoints one internal dependency — so it neither expands nor reduces the opportunity; it only confirms the package is still being maintained by its author. Recommendation: approve a timeboxed evaluation, treat it as an internal utility rather than a strategic dependency, and revisit once volume or multi-server requirements appear.

For engineering: Treat micro-module/enqueue-fs as a transport adapter for enqueue/enqueue, not a framework feature — expect no Laravel service provider, no Horizon integration, and no observability out of the box. Its value is brokerless dev/CI parity and a deployable path for air-gapped or single-node installs. Its cost is ownership: vendor and pin it, write a thin internal producer/consumer interface around it, and add tests for the failure modes a filesystem cannot handle for you (torn writes, stale locks, disk pressure, concurrent consumers on the same directory). Release 0.10.21 swaps enqueue/dsn for micro-module/dsn, so budget a line item for verifying DSN parsing on your actual connection strings, pinning micro-module/dsn alongside the transport, and re-reading the dependency tree for further micro-module/* additions in future bumps. Benchmark before rollout; verify behavior on any network filesystem; and keep the database driver behind the same interface as the documented exit ramp so the transport remains a one-line configuration decision.