Helper Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip for the "utility layer." Every product accumulates a thin layer of glue code — slugging, truncation, nested array access, number and date formatting. This package is a candidate to absorb that layer instead of paying sprint capacity for it. The PM decision is not "is this good?" but "is writing ~50 lines of typed, first-party helpers cheaper than owning an unadopted dependency?" For most Laravel teams, the answer is yes — which makes this package a useful reference point when codifying that policy rather than an actual purchase.
• Dependency governance and risk tiering. A 0-star, 0-dependent, MIT-licensed convenience library is the textbook example of a "low-risk / high-replaceability" tier. Use it to make the tiering concrete: what qualifies for auto-approval, what needs an ADR, what gets vendored. This is a policy artifact, not a roadmap item.
• Feature scoping for internal and admin tooling. The realistic use case is back-office CRUD, integration scaffolding, import/export formatting, and discovery-phase prototypes where speed beats polish and the helper layer is cheap to swap later. It should not touch revenue, checkout, auth, or compliance paths.
• Standardizing conventions across squads. If two or more teams are independently reimplementing the same string/array/formatting helpers, a single shared surface reduces drift and review friction. That decision is organizational. The package could seed a first-party app/Support/ module even if the package itself is never installed.
• Ecosystem positioning (conditional). IDLab is a Geneva-based digital lab. If the roadmap touches Swiss public-sector or non-profit integrations, aligning with their conventions may reduce future integration cost. Absent that, there is no strategic rationale.
• Roadmap: not now. This does not earn a slot ahead of funded work. Log the evaluation, close it, and revisit only if a named, concrete gap appears.

When to Consider This Package

Consider it only when all of the following hold:

• A specific helper is named. Not "helpers in general" — an actual function you can point at, that you are already writing, in two or more projects. If the need is still hypothetical, stop.
• Someone has read the source. Budget half a day for a senior PHP developer to catalogue the public surface, check test coverage, confirm PHP version support (target 8.2+), and check the last commit date. Zero dependents means you are the de facto QA.
• The framework question is answered. The -bundle suffix is Symfony terminology, not Laravel. Laravel ships Symfony components but not the HttpKernel/DependencyInjection bundle system, so IdlabHelperBundle will not register in config/app.php. Expect to use it as framework-agnostic source, or to write a bridge — and price that in.
• You are prepared to own it. MIT makes forking trivial; it does not make forking free. Plan to copy the subset you need into a first-party namespace with attribution, your own types, and your own tests, rather than adding a runtime composer.json requirement.
• It clears the first-party bar. Laravel already covers most of this surface via Str, Arr, Collection, Carbon, and Number. The package must beat roughly 20 lines of first-party code to justify a review cycle.

Look elsewhere — or write it yourself — when:

• Community validation matters. Zero stars and zero dependents mean no signal that anyone outside the originating team runs this in production. No third-party bug reports, no battle-testing.
• You need support guarantees. No visible release cadence, security disclosure policy, or issue-tracker responsiveness. Disqualifying for anything on a revenue or compliance path.
• You're on a modern framework version. Unmaintained bundles are the classic source of PHP-major and framework-major upgrade blockers, and the migration cost lands on you.
• Nobody can audit it. If no engineer has review time this quarter, do not adopt. "MIT + installable via Composer" creates false reassurance that a supported dependency exists.
• You're on Laravel and expecting a package. It is not one. Framework-agnostic extraction may require unwinding service-container coupling — be ready to walk away if that coupling is deep.

How to Pitch It (Stakeholders)

For executives: idlab/helper-bundle is a small, MIT-licensed utility library from a Geneva-based digital lab that bundles common string, array, and formatting helpers. It is not a strategic investment. There is no community adoption, no visible maintenance signal, and it is a Symfony bundle rather than a Laravel package, so using it on our stack would mean extracting code rather than installing a dependency. It costs nothing and might save a small amount of developer time on internal tooling. Recommendation: do not add it as a platform dependency. Permit selective code extraction, pinned and attributed, only in non-critical internal projects, and treat it as a candidate for replacement by our own helpers if usage grows.

For engineering: Evaluate this as source code to read, not as a package to install. Budget half a day: read vendor/ or the repo, confirm whether it is Symfony-coupled, check test coverage and the last commit date, and look specifically for global function definitions, generic namespaces, and deprecated array-access patterns that would collide with our own code. If one or two helpers genuinely fill a gap, vendor them into app/Support/ with attribution and the MIT licence retained, add types and tests, and run PHPStan/Larastan before it lands. Do not add it to composer.json as a runtime requirement — that converts a bounded, copied cost into an unbounded upgrade liability with no upstream fix path. Record the decision in an ADR either way, so this does not get re-raised next quarter. And note the framing: the burden of proof sits with the package. If we cannot name the function we need, the correct answer is no, and we should close it out.