- What does the felixkiss/uniquewith-validator package do?
- It adds a unique_with validation rule to Laravel that extends the built-in unique validator so uniqueness can be enforced across a combination of columns rather than a single one. This is the recurring multi-tenant case where an email must be unique per account, a slug per site, or a SKU per vendor. The package is a deliberately thin adapter consisting of a service provider that calls Validator::extend, with no models, migrations, config file, or middleware. That means it adds essentially zero architectural footprint to an existing application.
- How do I install felixkiss/uniquewith-validator in a Laravel app?
- Installation is a single composer require felixkiss/uniquewith-validator command. Laravel package auto-discovery registers the service provider automatically, so there is nothing to add to your config files on supported versions. If you are on an older Laravel release without auto-discovery, register the provider manually in config/app.php. After that the rule is immediately available in your validator rule strings.
- How do I validate that an email is unique per company in Laravel?
- Pass the rule as a pipe-delimited string in your rules array, for example 'email' => 'unique_with:users,company_id', so the pair of company_id and email must not already exist in the users table. The first positional argument is the table name and every following argument is a column that must match. Because arguments are positional and stringly typed, readability and refactorability are limited compared with the Rule object API. Keep the rule defined statically in code rather than building it from request input.
- How do I ignore the current record when updating with unique_with?
- On updates you pass the ID of the row being edited as an additional positional argument after the columns, and you can supply the primary key column name as a further argument if it is not id. Take that ID from the route parameter or the authenticated model rather than from raw request input. Always verify the exact argument order against the README for your tagged release, since everything is positional. Testing the update path explicitly is worthwhile because getting the order wrong silently weakens the rule.
- Does unique_with support extra where clauses and custom column names?
- Yes, the package supports ignoring IDs, appending extra where conditions, and specifying custom column names, all through additional positional arguments in the rule string. That flexibility comes at the cost of clarity, because a long rule string is easy to misorder and hard to review. Confirm the exact syntax for your tagged version in the README before depending on it. For anything complex, the modern Rule::unique()->where() form is far more readable.
- Which Laravel versions does unique_with support?
- The package is aimed at Laravel 5.x through 8.x-era applications that express validation as pipe-delimited rule strings. Older releases of packages of this vintage frequently depend on global helpers such as array_get that were removed in Laravel 6, and on pre-Rule validation internals. Check the newest tagged release and its CI matrix, and confirm someone has exercised it on your target major in the last 12 months. If the last tag predates your runtime, treat it as adopting unmaintained code.
- What is the alternative to unique_with in modern Laravel?
- Laravel now covers the same ground with Rule::unique('users')->where(fn ($q) => $q->where('company_id', $companyId))->ignore($id). That approach gives you first-class framework support, IDE discoverability, and no third-party dependency. The mapping from a unique_with rule to this form is one-to-one and largely scriptable, so migrating is a mechanical change rather than a rewrite. On Laravel 9 and later, the Rule object form is the idiomatic choice for greenfield work.
- Do I still need a composite unique index in the database?
- Yes. The validator only issues a SELECT to check for an existing combination, it does not create or enforce an index. For every unique_with rule you plan, make sure a matching composite unique index exists on the table, and add one if it does not. Without that index, concurrent writes can still insert duplicate combinations between the check and the insert.
- How does unique_with handle soft deletes, nullable columns, and collation?
- The package offers no built-in opinion on soft-deleted rows, nullable columns, or case-insensitive collations, so behavior follows your query and the database index semantics. Decide explicitly whether a soft-deleted row should block a new combination, and test the case-sensitivity behavior against your actual collation. Do not assume the validator and the unique index agree on these edge cases without verifying them.
- Is felixkiss/uniquewith-validator actively maintained and safe for production?
- The dominant risk is framework version drift rather than code quality, so check the newest tag, its CI matrix, maintainer activity, and issue-response cadence before adopting it. The rule parses table and column names directly out of the rule string, which is safe when the rule is defined statically in code but a SQL injection vector if request input is ever interpolated into it. Because the entire surface is roughly one or two files, fork-and-vendor cost is low if the project stalls. For many teams the safer production choice is the built-in Rule::unique with where and ignore.