- Is amethyst/taxonomy a Laravel package or a framework-agnostic PHP library?
- The Amethyst collection is described as a set of small, framework-agnostic PHP building blocks, and the technical assessment finds no Laravel service provider, config, or Eloquent models. The package blurb markets flexible taxonomy support for Laravel models, so treat Laravel compatibility as something you add through an adapter rather than something it ships. Verify the actual composer.json and source before assuming drop-in Laravel behavior.
- How do I install amethyst/taxonomy with Composer?
- Install it with Composer, for example composer require amethyst/taxonomy, and check that its PHP and transitive dependency constraints intersect your runtime before merging. Because it is PSR-4 and MIT-licensed, packaging and legal checks are straightforward. You will still need to register your own Laravel bindings and adapter classes, since the package does not publish a service provider.
- Does amethyst/taxonomy support hierarchical categories and nested terms?
- The blurb claims categories, tags, and hierarchical terms, but the assessment flags hierarchy depth, parent/child behavior, and multi-taxonomy assignment as questions to verify. There is no compatibility matrix or rich documentation to confirm N-depth support. In your spike, model a two-level taxonomy and inspect the API and tests before relying on it for governed classification.
- Can I attach taxonomies to multiple Laravel models polymorphically?
- The overview says taxonomies can be attached polymorphically, but the package does not ship Eloquent models, migrations, or pivot tables for Laravel. You will design the polymorphic pivot or JSON column schema and map package terms into your persistence layer. Keep that mapping behind your own repository contract so call sites do not depend on package internals.
- Does amethyst/taxonomy provide migrations, Eloquent models, or a Laravel service provider?
- No: the evaluation explicitly notes that it provides no Eloquent models, migrations, admin UI, REST endpoints, published config, factories, or Laravel service-provider bindings. You must add migrations for terms and pivots, container bindings, caching, and serialization yourself. Budget this adapter and schema work as part of adoption, not as an afterthought.
- Which PHP and Laravel versions are supported by amethyst/taxonomy?
- The package declares PHP and dependency constraints in its composer.json, but the assessment warns that Amethyst packages tend to track older PHP baselines and there is no published Laravel compatibility matrix. Check the constraints against your runtime and run composer why-not or a constraint check to catch conflicts in composer.lock. Confirm transitive dependency overlap with your existing packages before committing.
- How do I query records by taxonomy term without N+1 queries in Laravel?
- There is no documented batch or preload path in the provided material, and term resolution may require N+1 queries if you map terms naively. Measure query behavior in the spike, then add eager loading, join-based repository queries, or a cache layer in your adapter. Keep query construction in your own repository so you can optimize without changing call sites.
- Is amethyst/taxonomy maintained and safe to use in production?
- Adoption signals are weak: zero stars and zero dependents at evaluation time, a single maintainer, and no observable production usage. The MIT license lets you fork or vendor the code, but only after an audit confirms it is small enough to own. Treat it as high risk for production until you verify tests, release cadence, and maintenance activity yourself.
- How does amethyst/taxonomy compare to Laravel-native tagging packages like spatie/laravel-tags?
- Laravel-native packages such as spatie/laravel-tags or nested-set libraries already provide Eloquent models, migrations, and service providers, so they are a better fit for simple free-text tagging. Amethyst Taxonomy may make sense only if you want reusable, governed classification as a first-class domain concern and are willing to build the Laravel adapter. Run a spike and compare query ergonomics, hierarchy support, and maintenance risk rather than assuming the Amethyst label implies Laravel integration.
- How should I integrate amethyst/taxonomy into an existing Laravel app and is there a migration path?
- Adopt it greenfield behind your own TaxonomyRepository interface: define DTOs and contracts independently, implement them with the package internally, and keep application code on your contract. There is no migration from another framework, but if you already store categories or tags elsewhere, plan a backfill and dual-write window. Start with one non-critical entity in a single service and use a decision gate before promoting it.