# Laravel Love: weighted, typed social reactions for Eloquent models

> Laravel Love makes any Eloquent model reactable, with a reaction type system for the emotions and a weighted reaction system for the scores. It installs with Composer and a migration, and its last push was on 2026-04-17.

**cybercog/laravel-love** — Add Social Reactions to Laravel Eloquent Models. It lets people express how they feel about the content. Fully customizable Weighted Reaction System & Reaction Type System with Like, Dislike and any other custom emotion types. Do you react?

- Repository: https://github.com/cybercog/laravel-love
- Website: https://komarev.com/sources/laravel-love
- Stars: 1,202 · Forks: 77
- Language: PHP
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/cybercog-laravel-love

## Any Eloquent model becomes reactable

Laravel Love adds social reactions to Laravel Eloquent models. The pitch in the repository description is that it is the emotional part of an application: it lets people express how they feel about the content, and it makes any model reactable in a few minutes.

The design is built around two systems that are named in the description and that are worth separating, because they solve different problems.

The reaction type system defines the vocabulary. Like and Dislike are the obvious starting points, and the types are fully customizable, so the same package covers an upvote, a star, a favorite, a kudo, an adore or a rating as well as the emotion cases the package name suggests. The repository topics list the range of names this has been used for, from adore and cog to election, kudo, love, rate, rating, star and vote, which is a reasonable hint about the shapes of application it is meant for.

The weighted reaction system is the part that separates it from a like button. Each reaction can carry a weight, so a reaction is not a flag but a value, and the aggregate of those values is a score. That is what makes a comment, an answer or an article rankable without a separate voting implementation.

The package is deliberately pitched at applications rather than at demos. The README lists the implementations it draws on, GitHub Reactions, Facebook Reactions, YouTube Likes, Slack Reactions, Reddit Votes and Medium Claps, and says the package was developed with the idea that it should cover all the possible use cases and be viable in enterprise applications. The author is Anton Komarev, the package is published by CyberCog, and the full guide lives at the Laravel Love Guide.

## Composer install, one migration

The installation is the standard two steps for a Laravel package.

```shell script
$ composer require cybercog/laravel-love
```

```shell script
$ php artisan migrate
```

The package is pulled in through Composer and the migration creates the tables that hold the reactions. Since the reactions are a first-class part of the domain rather than an afterthought, the schema arrives with the package, and the reaction type configuration lives in the `config/` directory of the repository.

The repository layout tells you what else is in the box. There is a `src/` directory for the implementation, a `contracts/` directory for the interfaces the package exposes, a `database/` directory for the migrations, a `config/` directory, and a `tests/` directory. `composer.json` and `phpunit.xml.dist` sit at the root next to `CHANGELOG.md`, `UPGRADING.md` and `CONTRIBUTING.md`.

Upgrading is taken seriously enough to have its own document. The README points to `UPGRADING.md` for detailed upgrade instructions, and the changelog at the root carries the history. The version numbering is worth a glance, because the recent releases move quickly: 10.2.0 was published on 2026-02-28, 10.2.1 on 2026-03-01 and 10.2.2 on 2026-04-17. A major version number of ten on a package that has been around for years means the upgrade path between majors is a real event, and the upgrading document exists for that reason.

## The reaction type and the weight are separate decisions

The two systems mentioned in the description are the whole API surface, and the reason to keep them apart is that they answer different questions.

The reaction type system answers what a reader is allowed to feel. That is a configuration decision, and it is the one that touches the user interface, the translation strings and the data you have to migrate if you add a type later. Adding a new emotion is a content change, not a code change, and that is what makes the package usable in an application whose reaction vocabulary is a product decision rather than a developer's.

The weighted reaction system answers how much a reaction counts. If every reaction is worth one, the package behaves like a like counter and the weight is irrelevant. If a reaction can be worth more, the aggregate becomes a score, and the score is the thing you sort by, show in a leaderboard, or threshold to unlock something. The description of the package as a fully customizable weighted reaction system and reaction type system is a claim about both axes being configurable, and the type axis is where the flexibility matters most in practice.

The consequence for a design is that the two decisions are made at different times. Types are usually set before launch, and weights are usually tuned after launch, once there is data to look at. A schema that hard-codes one integer column per emotion does not allow either of those to change later without a migration, which is the problem the package is solving.

## The test matrix runs PHP 8.1 to 8.5 in containers

The development setup is in the repository, and it is unusually legible because the whole matrix is declared in one file.

The `compose.yml` at the root defines a service per PHP version, from `php81` through `php85`, each with a matching container name and image, each built from `./.docker/php.Dockerfile` with the PHP version passed as a build argument:

```yaml
  php83:
    container_name: laravel-love-lib-83
    image: laravel-love-lib-83
    build:
      context: ./
      dockerfile: ./.docker/php.Dockerfile
      args:
        PHP_VERSION: "8.3"
```

Each service runs with a tty, uses `/app` as the working directory and mounts the repository into it, so the test suite runs against the working tree in the container rather than against a copy. The `PHP_VERSION` build argument is what makes one Dockerfile serve five services, which is a small piece of design that keeps the matrix cheap.

The rest of the quality tooling is in the root as well. `.phpstan.neon` is the static analysis configuration, `.phpactor.json` is the editor and IDE configuration, `.scrutinizer.yml` is the hosted code quality service, `.styleci.yml` is the hosted style checker, and `phpunit.xml.dist` configures the test runner. There is an `.editorconfig`, a `.gitattributes` and a `.gitignore`.

The `AGENTS.md` and `CLAUDE.md` files at the root are for coding agents working in the repository, and they sit alongside `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`.

## MIT for the code, a separate licence for the logo

The licence section of the README is short and splits the project into two pieces.

The `Laravel Love` package is open-sourced software licensed under the MIT license by Anton Komarev, with the text in the `LICENSE` file at the root of the repository. The `Devil` logo image is licensed separately under Creative Commons 3.0 by YuguDesign.

That split is worth noticing because it is the kind of thing that trips up a compliance review. MIT is permissive and standard for a Composer package, and the asset clause is narrower: the logo is a Creative Commons work with attribution requirements, so a project that rebrands the package or ships the icon under a different product name has a different obligation from the code itself. It is a small detail, and it is the kind of small detail that is easier to handle when it is stated in the README rather than discovered later.

The project is not archived, and the last push to the repository was on 2026-04-17, which is the same day as release 10.2.2. The releases before that are 10.2.1 from 2026-03-01 and 10.2.0 from 2026-02-28. In other words the visible activity stops in April 2026, and anyone picking this up now should plan for a version of it that does not move on its own.

## Where the package is the wrong tool

The case for the package is that it gives you a reaction vocabulary and a scoring model without writing either, and it does it the way a Laravel application expects, through migrations, configuration and Eloquent relations.

The case against is mostly about proportion. A site that needs one favorite button needs a boolean column and one relationship. Adding a reactions subsystem, a type configuration, a weight column and a migration to a project that will never have a score is a dependency, a schema and a set of upgrade steps in exchange for nothing. The package is aimed at applications where reactions are a domain concept, and the README itself says it was built to cover all the possible use cases, which is another way of saying it is more than some applications need.

The second limitation is the state of the project. The last push was on 2026-04-17 and the newest release carries the same date, so a team that adopts it is adopting a version that is not being changed, and it has to plan for that: pinned versions, a fork, or an internal replacement.

The alternative approach is worth describing rather than dismissing, because it is close to what the package does. A hand-rolled implementation on plain Eloquent is a many-to-many relation between your model and a reactions table, with a type column and a weight column, plus a service that applies and reverses a reaction so that the same user does not react twice to the same object. That is a day of work for a small team, and it gives full control of the schema and no dependency to keep current. What the package adds is the parts that are tedious rather than hard: the reaction type configuration, the handling of weights in aggregate queries, the migrations that keep the two systems consistent, and the Eloquent integration that makes a model reactable with a trait. The trade is dependency for that convenience, and the trade is worth making only when reactions are central to the product.

## Conclusion

Laravel Love fits a Laravel application that needs more than a single like column, where the reaction vocabulary has to be configurable, where a comment can carry a score, and where the same behaviour should work across several models without writing the tables by hand. It is the wrong choice for a small project that only needs a boolean favorite, because the two systems, the migrations and the configuration are more than that use case needs, and it is a poor match for a team that wants a maintained dependency today, because the last push was on 2026-04-17 and the latest release, 10.2.2, carries the same date. Before adopting it, read `UPGRADING.md` for the upgrade path between major versions, check that the reaction type configuration in `config/` matches the emotions your interface offers, and decide early whether the weighted reaction system is the model you want, since that choice changes the schema rather than just the UI.

## FAQ

### How do I install Laravel Love?

Pull the package in with `composer require cybercog/laravel-love` and then run `php artisan migrate` to create the reaction tables. Detailed upgrade instructions between versions are in the UPGRADING.md file, and the changelog is in the repository root.

### Which reaction types does Laravel Love support?

The reaction type system is fully customizable and includes Like and Dislike along with any custom emotion type, and the separate weighted reaction system lets a type carry a value so reactions can be aggregated into a score.

### Which PHP versions does Laravel Love test against?

The compose.yml in the repository defines services for PHP 8.1, 8.2, 8.3, 8.4 and 8.5, each built from .docker/php.Dockerfile with the PHP version passed as the PHP_VERSION build argument.

### Is Laravel Love still being released?

The repository is not archived, but the last push was on 2026-04-17 and the latest release, 10.2.2, carries the same date. The two releases before it are 10.2.1 from 2026-03-01 and 10.2.0 from 2026-02-28.

## Sources

- [cybercog/laravel-love on GitHub](https://github.com/cybercog/laravel-love)
- [License: MIT](https://github.com/cybercog/laravel-love/blob/master/LICENSE)
- [Project website](https://komarev.com/sources/laravel-love)
- [README](https://github.com/cybercog/laravel-love/blob/master/README.md)
- [Releases](https://github.com/cybercog/laravel-love/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cybercog-laravel-love