- How do I install anil/comments in a Laravel application?
- Install it with Composer using composer require anil/comments, then let Laravel's package auto-discovery register the service provider. Publish the package assets with php artisan vendor:publish so you get the config file and migrations, review them, and run php artisan migrate. Finally, add the package's commentable trait to each Eloquent model that should accept comments. Because the v2.0.0 publish surface may include language files and admin views, check exactly which tags vendor:publish exposes before running migrations in a shared environment.
- Can I add comments to any Eloquent model with anil/comments?
- Yes. The package is built around a polymorphic commentable trait, so a single comments table can serve Documents, Tickets, Invoices, Projects, or any other model. You attach the trait to each model you want commentable and the package resolves the morph relation for you. This is the main reason to choose it over a per-domain build, but you should still register a morph map so class names in the database stay stable if you refactor.
- Does anil/comments support threaded or nested replies?
- Yes, the package supports nested replies through a parent reference on the comments table, giving you threaded conversations rather than a flat list. The important caveat is query strategy: rendering deep threads can produce N+1 queries if you lazy-load children per comment. Eager-load the reply relation with a depth limit, or query the whole thread for a commentable in one pass and build the tree in memory.
- Which Laravel and PHP versions does anil/comments support?
- Check the require block in the package's composer.json before you commit, because version constraints are the only authoritative statement of support. The 2.0.0 release is recent and the documentation is thin, so do not assume backward compatibility with older Laravel or PHP versions. Verify the constraint against your application's framework version and add a composer update dry run to your spike. If your app runs an older Laravel LTS, test on a branch first rather than assuming it will resolve.
- How does comment moderation work in anil/comments?
- The package ships a moderation state on the comments table, so comments can be held as pending and only shown once approved. Version 2.0.0 also adds an admin surface for reviewing and actioning those states. Inspect the published migration to see the exact status values and defaults, then decide whether your application sets the initial state itself rather than relying on the package default. If you need multi-step workflows, build your own states on top rather than assuming the package mirrors them.
- What changed between anil/comments 1.0.1 and 2.0.0?
- It is a major version bump with no published migration guide and a changelog consisting of only a few PR titles, so the breaking changes are not enumerated. That means you cannot tell the difference between breaking changes that do not affect you and ones that silently alter query behavior. Read the diff between the two tags, focusing on the trait, the migrations, and the query builder, before upgrading an existing install. Treat any earlier evaluation notes as stale, since 1.x was effectively pre-1.0 stabilization.
- Does anil/comments auto-register admin routes and views, and can I disable them?
- Version 2.0.0 adds an admin surface, and in Laravel packages that conventionally means package-owned routes, controllers, Blade views, and middleware loaded by the service provider. Those routes are a live application surface the moment the package is installed, not when you choose to enable the feature. Confirm whether the provider guards route registration behind a config flag, what prefix and middleware group they use, and how to turn them off. Also check what authorization guard the admin UI assumes, since an unguarded admin route in a production app is an immediate risk.
- Is anil/comments safe to use in production?
- It is a single-maintainer package with negligible community adoption, no commercial backing, and no SLA, so you own the risk. Known concerns to verify in a spike include the threading query strategy, absent authorization policies, XSS if comments are rendered raw, migration collisions, morph map drift, and orphan cleanup after hard deletes. The extensive testing claim lives in a PR title rather than a CI badge, so ask for the workflow file and confirm the matrix covers MySQL, Postgres, and SQLite. For low-risk internal collaboration features it is a reasonable trade; for anything customer-facing, budget for a fork you control.
- How do I change the comments table name or database connection?
- Publish the migrations and edit them, or override the table and connection in the published config if the package exposes those keys. Renaming the table in the migration is usually simpler than fighting config indirection, and it avoids collisions with an existing comments table. Whichever route you take, keep the change in your own migration set so a future composer update does not silently re-publish the original schema. Pin the package version if you modify published files.
- Are there alternatives to anil/comments for adding comments in Laravel?
- The realistic alternative is building on Laravel's native morphMany relation yourself: a comments table with commentable_type, commentable_id, and parent_id gets you most of the data layer in an afternoon. That path gives you full control over authorization, query strategy, and rendering, which is where third-party comment packages usually fall short. If you do evaluate other packages, compare them on CI coverage across database engines, release discipline, and whether admin routes and views are optional. Weigh any candidate against the two-to-six week build you are trying to avoid, and against the ongoing cost of maintaining a low-adoption dependency.