Common Laravel Package

Product Decisions This Supports

• Build vs. buy for a shared utility layer. bolt/common is plumbing — the helper/utility classes shared across Bolt's own packages. The decision it informs is whether to reuse an existing internal-utility baseline or spend sprint capacity writing our own string/array/filesystem/JSON helpers.
• Ecosystem alignment, not differentiation. This is not a feature source and will not move a roadmap item. Its value is measured in avoided glue code and compatibility with Bolt internals if we build on, extend, or migrate within Bolt.
• Extension and integration scope. If we ship Bolt extensions, import/export scripts, or content-migration tooling, this package sets the default idioms our engineers will reach for — which affects estimates for integration work.
• Dependency and maintenance exposure. Last release Nov 2021, ~18 stars, and an unverifiable upstream repository are themselves decision inputs: they should trigger a supportability review before it lands anywhere near a customer-facing surface.
• Not a candidate for platform standardization. On the evidence available (low adoption, stale, unknown provenance), it does not belong on an approved-dependency list for new products.

When to Consider This Package

Consider it when:

• We are already inside the Bolt ecosystem (a Bolt-based site, extension, or upgrade path) and need behavior that exactly matches Bolt's own helpers.
• We need output parity with Bolt — identical normalization, serialization, or filesystem semantics — and reimplementing risks subtle drift.
• It is a transitive dependency we are inheriting anyway, and the question is only whether to pin, vendor, or replace it.

Look elsewhere when:

• The project is greenfield Laravel. illuminate/support (Str, Arr, Collection, Number) is better documented, actively maintained, and already in the framework — adding a second utility vocabulary is pure overhead.
• We need assured security maintenance. No release since 2021 plus an unverifiable repository means no reliable path for CVE response; that fails most procurement and due-diligence gates.
• We need breadth. Symfony components or a well-maintained, widely adopted package gives more surface with more eyes on it.
• The repository cannot be confirmed. Treat unknown provenance as a blocker until we have an internal mirror and a named owner.

If adopted: pin the exact version, vendor or mirror the source, and wrap it behind a thin internal adapter so swapping to illuminate/support later is a one-file change rather than a refactor.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility library from the Bolt CMS ecosystem — low cost, no licensing risk, but also low strategic value. It saves a modest amount of engineering effort only if we are already working inside Bolt. The real finding is the risk profile: roughly 18 stars, no release since November 2021, and an unverifiable source repository. Recommendation: treat it as an inherited dependency to be contained and replaced over time, not a building block we standardize on.

For engineering: bolt/common is the shared helper layer underpinning Bolt's packages. Adopt it only for behavioral parity with Bolt internals; do not introduce it into new Laravel work, where illuminate/support already covers the same ground with active maintenance. If we take it, pin the version, mirror the source internally, isolate all call sites behind our own adapter, and log a follow-up to migrate to framework-native utilities. The maintenance signal — no release in over four years, minimal community — means we should assume we may end up owning this code ourselves.