Splat Laravel Package

Product Decisions This Supports

• Build vs. buy for pattern matching. Glob matching looks trivial and isn't: recursive **, brace expansion {a,b}, escaping, and Windows vs. POSIX separators are a multi-day edge-case project. This package turns that into a one-line composer dependency and lets engineering spend the time on the actual feature.
• Whether to expose glob syntax to users. If matching is cheap and reliable, "include/exclude patterns" becomes a shippable power-user feature (ignore lists, watch paths, import mappings, backup/export filters, asset pipelines, plugin or fixture discovery) rather than a support burden or a permanently deferred roadmap item.
• Scope of the first release. Decide between a curated picker/preset UI and a free-text pattern field. The library choice doesn't force this, but its presence lowers the cost of the more flexible option — useful when evaluating competitive parity ("flexible file rules" is a checkbox competitors already have).
• Architecture and reversibility. Committing to a small matcher behind an internal PathMatcher-style interface keeps the vendor choice non-load-bearing, so this is a low-regret decision even if we swap implementations later.
• Cross-platform support commitments. Consistent matching across macOS, Linux, and Windows directly affects QA scope and support ticket volume; a library that normalizes separators buys down that cost.
• Sequencing adjacent roadmap work. Log/file tooling, bulk operations, static export rules, and CI/config filtering all depend on the same primitive; adopting it once unblocks several items instead of re-litigating each.

When to Consider This Package

Adopt when:

• You need recursive (**) and/or brace ({a,b}) matching — the two things fnmatch() and Laravel's Str::is() do not cover.
• You're matching strings or paths as data (validation, rule engines, filtering config), not necessarily walking a filesystem.
• You want a framework-agnostic, dependency-light library that drops into Laravel with no service provider and no config publishing.
• MIT licensing and a recent release (Dec 2024) satisfy your supply-chain bar, and the small API surface is a feature rather than a warning sign.

Look elsewhere when:

• You need traversal, iteration, sorting, and filtering in one API → Symfony Finder (frequently already present transitively).
• You need true .gitignore semantics — negation, anchoring, directory-only rules. Glob is not gitignore; conflating them creates subtle, user-visible bugs.
• You need a virtual filesystem abstraction → Flysystem.
• You only need simple * wildcards → Str::is() or fnmatch(); no dependency is justified.
• You need a large, heavily-audited community footprint → prefer the more established glob implementation, even if it ships less often.

Risks to price in: ~106 stars and a small maintainer base mean real bus-factor risk. The source is small enough to audit in an afternoon — do that, pin the version, and wrap it. Also validate behavior with user-supplied patterns before exposing them broadly: pathological patterns and separator handling are where this class of library typically bites.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed utility that lets us ship flexible file and path rules — include/exclude patterns — in [feature] without a bespoke engineering project. The cost is one composer dependency; the risk is low and reversible because it sits behind our own interface and touches no data models, auth, or infrastructure. It converts a "someday" roadmap item into a sprint-sized one.

To engineering: Standalone PHP, no Laravel coupling, no service provider, small surface. It covers recursive and brace-expanded glob patterns that fnmatch and Str::is can't, which is the whole reason to take the dependency. Keep Symfony Finder for traversal if we need it; use this strictly for matching. Wrap it in a PathMatcher interface so we can swap to Finder or a regex-based implementation if throughput or semantics demand it. Add tests for Windows separators, **, braces, and hostile user input, and cap pattern complexity at the boundary.

Recommendation: Adopt narrowly, behind an interface, with a documented fallback path.