Support Laravel Package

Getting Started

artemeon/support is a small utility/support package for Laravel projects. 0.2.0 is the first release that widens the illuminate/support constraint to ^13, so it is the version to pin if you are on Laravel 13.

1. Install it:

   composer require artemeon/support:^0.2
   

2. Confirm the resolved framework version and PHP requirement:

   composer show artemeon/support
   

3. Look first at the package's src/ directory and its test suite (tests/). Because this package ships with Pest mutation-testing and type-coverage workflows, the tests double as the most reliable usage documentation — read a test before you read a class.

4. First use case: pull the support helpers you need into a service or action class via constructor injection (or static helper calls where the package exposes them) and delete the ad-hoc private helpers you had previously duplicated across your app.

Implementation Patterns

• Depend on the package, not on Laravel internals. The whole point of a support package is to centralise behaviour that would otherwise be reimplemented in every project. When you find yourself writing the same array/string/collection manipulation in a third place, check whether artemeon/support already exposes it.
• Wrap static helpers behind your own boundary. Rather than calling package statics from controllers, expose them through a small app-level service or a dedicated helper file. This keeps the pre-1.0 API surface isolated to one place in your codebase and makes the eventual 1.0 migration a one-file change.
• Inject where the package allows it. If a class is resolvable from the container, resolve it; this makes it trivial to swap in a fake in tests.
• Keep the constraint tight. With 0.2.x you are in 0.x semver territory, where minor bumps are allowed to break. Pin ^0.2 rather than ^0.0 or *, and commit composer.lock.
• Test alongside the package's own style. If your project uses Pest, mirror the package's approach — mutation testing and type coverage are cheap to enable and catch exactly the kind of edge cases utility code accumulates.
• Upgrade path for Laravel 13. If you were previously held back on illuminate/support 12, 0.2.0 removes that blocker. Bump the package first, then bump the framework, and run your full suite in between so you can attribute any failures correctly.

Gotchas and Tips

• Pre-1.0 API churn is the main risk. 0.2.0's changes are internal (test tooling refactor) plus a widened constraint, but the jump from 0.1.6 to 0.2.0 is a minor bump under 0.x semver, which permits breaking changes. Read the diff between tags before upgrading in a large codebase.
• The release notes describe the package's own CI, not your app. The Pest mutation-testing and type-coverage work in PR #5 affects the maintainers' pipeline. It is a positive quality signal (the utility code is mutation-tested), but it does not add consumer-facing features — do not go looking for new public API in this release.
• Laravel 13 constraint is the only user-facing change. PR #6 (Allow illuminate/support ^13) is the reason to upgrade. If you are on Laravel 12 or below, 0.2.0 buys you nothing functional and you can defer.
• Check the PHP floor before upgrading CI images. A widened framework constraint sometimes comes with a raised php requirement in composer.json; verify with composer why-not php if installs fail.
• Debugging: if a helper behaves unexpectedly, reproduce it in a Pest test using the package's own test fixtures rather than in a tinker session — the fixtures encode the intended input shapes.
• Extension points: prefer composing the package's utilities into your own classes over forking or copying them into app/Support. If you genuinely need different behaviour, wrap and override locally so you can still take patch releases.