- Can I use kreyu/nip-validator-bundle directly in a Laravel application?
- No. It is a Symfony bundle: it ships a Bundle subclass, a DI extension, and Constraint classes that rely on Symfony's Validator component and constraint registry. Laravel boots its own container and uses Illuminate\Validation with the Rule contract, so the bundle cannot be installed and used as-is in a Laravel app. Only the underlying checksum arithmetic is portable, which is why the common recommendation is to reimplement it as a first-party Laravel validation rule.
- How do I install and use the NIP constraint in a Symfony application?
- Install it with composer require kreyu/nip-validator-bundle and enable the bundle in your kernel or bundles.php as required by your Symfony version. You then apply the Nip constraint to an entity property or form field, either via an attribute such as #[Nip] or by passing a new Nip() instance into your form type's constraints option. The bundle targets Symfony 6.1 and newer.
- Does kreyu/nip-validator-bundle support Laravel 10 or Laravel 11?
- It does not target Laravel at all. The package is a Symfony bundle with Symfony Validator dependencies, and its PHP 8.1+ baseline happens to align with Laravel 10 and 11 minimums but that is coincidental. Adding it to a Laravel composer.json gives you Symfony framework plumbing you cannot boot, plus a heavy symfony/validator transitive dependency. For Laravel you should vendor or reimplement the roughly 50 lines of NIP checksum logic instead.
- What exactly does the NIP constraint validate: format, checksum, or both?
- It validates both the format and the checksum of 10-digit Polish NIP numbers. The check is the standard weighted sum modulo 11, and values whose remainder equals 10 are rejected as invalid. That algorithm is a stable statutory constant, so it does not drift over time even though the package itself has not been updated since March 2023.
- What is the difference between the Nip and Tin constraints in this bundle?
- The bundle ships both a Nip and a Tin constraint, but the Tin semantics are not obvious from the public surface. It may be a generic alias or it may validate a genuinely different format with a different country scope or length. Confirm by reading the constraint source before relying on it, because misinterpreting Tin is a real correctness hazard. If you only need Polish NIP validation, use Nip and ignore Tin.
- Does the validator normalize input such as dashes, spaces, or a PL prefix before checking the checksum?
- This is not documented clearly in the bundle overview, so treat it as unknown until you inspect the constraint source. Many validators reject any non-canonical string, meaning NIP values with dashes, spaces, or a PL country prefix fail format checks. The safe pattern is to strip separators and the PL prefix in a form request or DTO before validation, then validate a clean 10-digit string. Document that normalization rule explicitly for the business owner.
- How do I customize or translate the NIP validation error message?
- The bundle provides translatable, customizable error messages through Symfony's translation system. You override the message by setting the message option on the constraint or by supplying your own translation catalogue entry for the bundle's translation domain. In a Laravel reimplementation you would instead put the copy in a lang file and return it from your custom rule's message method.
- Is kreyu/nip-validator-bundle actively maintained and safe to depend on in production?
- It has a single maintainer, zero dependents, and a last release dated 2023-03-23, with Symfony 7 support not confirmed. The domain logic is low-risk because the Polish NIP checksum is stable and well specified, so staleness is mainly a packaging and supply-chain concern rather than a correctness one. If your target really is Symfony 6.1 or 6.2, pinning the version and treating it as a vendored fork candidate is reasonable. If your target is Laravel, do not add it to composer.json at all.
- What is the best way to validate Polish NIP numbers in Laravel?
- Implement a first-party class that satisfies Illuminate\Contracts\Validation\ValidationRule and performs the 10-digit format check plus the weighted mod-11 checksum. Register user-facing messages in a lang file and add Pest or PHPUnit coverage against a corpus of known valid and invalid NIPs. This costs roughly one engineer-day and removes an abandoned, Symfony-only dependency from your stack. Bridging symfony/validator into a Laravel rule is technically possible but adds a second validation paradigm for no benefit.
- How should I test NIP validation, especially the remainder-equals-10 edge case?
- Use a fixed corpus of real valid NIPs and deliberately broken variants covering wrong length, non-digits, bad check digits, and the edge case where the weighted remainder equals 10. Property-based or generated-input tests are cheap here and reliably catch that mod-11 edge case, which hand-picked examples often miss. Also add cases for normalized input with dashes, spaces, and a PL prefix so the normalization contract is locked down. Run these against your own rule class rather than the Symfony constraint.