Weave Code
Common Laravel Package
amethyst/common
Amethyst Common is a lightweight PHP/Laravel package of shared helpers, traits, and support classes. It gives projects and companion packages a consistent foundation for common utilities, reducing duplication and keeping application code simpler and easier to maintain.
At a glance
Frequently asked questions about Common
- Is amethyst/common a Laravel package?
- No. amethyst/common is a component of the Amethyst PHP framework, which is built on Symfony components rather than Illuminate. It ships shared helpers, traits, and support classes for Amethyst projects, not Laravel service providers or facades. You can consume it as a plain PHP library, but Laravel will not auto-discover or integrate it.
- Can I install amethyst/common in a Laravel app with Composer?
- You can run composer require amethyst/common, but installation is only the first hurdle. There is no Laravel auto-discovery, service provider, or config publishing, so you must instantiate classes directly. Before committing, run a dependency-resolution spike because its transitive Symfony constraints may collide with the versions Laravel already ships. Treat it as a vendored utility rather than a framework dependency.
- Does amethyst/common support PHP 8.2, 8.3, and Laravel 11?
- The Amethyst ecosystem has been dormant for years, so modern PHP and Laravel support is unlikely to be validated. The package almost certainly does not declare support for PHP 8.2 through 8.4 or for current Laravel releases. Check composer why-not against your PHP constraint and against laravel/framework's Symfony pins in a throwaway branch. If resolution requires downgrading Symfony below Laravel's needs, do not proceed.
- What helpers and classes does amethyst/common actually provide?
- It is a shared substrate of small helpers, traits, and support classes that companion Amethyst packages rely on. Much of it is likely straightforward logic that could be reimplemented in a few dozen lines per class. Before adopting it, list the specific classes you need and audit their size and behavior. If any class is more than about 50 lines of simple logic, rewriting it is usually cheaper than carrying the dependency.
- Will amethyst/common conflict with Laravel's Symfony components?
- Very likely, or at least plausibly enough that you must test it first. Amethyst is built on Symfony components and may pin versions that Laravel's dependency graph does not allow. Run composer why-not amethyst/common against your PHP version and against laravel/framework's Symfony constraints. A failed resolution is a hard no; do not negotiate version pins to force it in.
- Does amethyst/common require amethyst/core, and what does that pull in?
- It may, because 'common' packages in modular frameworks are typically the shared layer for the rest of the framework. If it requires amethyst/core, you inherit kernel and bootstrapping concepts that compete with Laravel's container and provider lifecycle. Check the composer.json requires and run composer depends amethyst/common to see the full transitive graph. Hidden coupling is the main reason to avoid it inside Laravel.
- Is amethyst/common actively maintained and safe for production?
- The signals are poor: roughly 1 star, 0 Packagist dependents, and a bus factor of one. Zero dependents means no production user is stress-testing it against modern PHP runtimes and no downstream project is watching for regressions. The Amethyst ecosystem has been dormant for years, so there is no realistic security-response or bug-fix path. For production Laravel work, treat it as abandoned unless you are prepared to fork and maintain it.
- Does amethyst/common offer a service provider, facade, or config file for Laravel?
- No. There is no Illuminate service provider, no facade, no config publishing, and no Laravel package auto-discovery. Everything must be wired manually by instantiating the classes or binding them in your own service provider. That also means no framework-level lifecycle integration, so you own all bootstrapping and cleanup.
- What are good alternatives to amethyst/common in a Laravel project?
- Start with native Laravel primitives: Str, Arr, Collection, helpers, and the Illuminate support package cover most string, array, and support-class needs. For anything else, a standalone Symfony component or a small internal helper class is usually a better fit than a dormant framework component. If you only need a handful of methods, copy the logic into your app under your own tests. The best alternative is almost always reimplementation, not adoption.
- How can I safely use amethyst/common in Laravel if I really have to?
- Isolate it behind a thin internal adapter interface so your application code never references Amethyst classes directly. Identify the exact classes in use, write tests around the adapter's behavior, and treat the package as a replaceable implementation detail. That converts a future removal into a single-file swap. Plan the exit before the entrance, because there is no upstream migration path.
Weaver
How can I help you explore Laravel packages today?