- Is roukmoute/hashids-bundle a Laravel package?
- No. It is a Symfony bundle that registers a Hashids service and a controller argument value resolver through Symfony's DI container. It has no Laravel service provider, facade, or publishable config/hashids.php file, so it is not directly consumable in a Laravel application.
- How do I use Hashids in a Laravel app instead of this bundle?
- Install the upstream hashids/hashids library with Composer and bind a configured instance in a Laravel service provider. Mirror the bundle's config surface in config/hashids.php for salt, minimum hash length, and alphabet, then inject the service or resolve it where needed. This gives Laravel the same encode and decode behavior without adding Symfony DI integration.
- What does roukmoute/hashids-bundle actually do?
- It integrates the Hashids PHP library into Symfony so numeric IDs can be encoded into short, reversible, non-sequential strings and decoded back again. It supports single or multiple integers, configurable salt, minimum hash length, and alphabet, and use through the provided service or Twig filters. The main use case is keeping database IDs out of URLs and public APIs.
- How do I install and enable roukmoute/hashids-bundle?
- In a Symfony application, install it with Composer and register the bundle if Symfony Flex does not do that automatically. Then configure the salt, minimum hash length, and alphabet once and inject the Hashids service where encoding or decoding is needed. Do not install it as a Laravel package; use hashids/hashids there instead.
- Where do I configure the Hashids salt, minimum length, and alphabet?
- Configure those values in the Symfony bundle configuration so the DI service is built with the correct Hashids settings. For a Laravel equivalent, place the same values in config/hashids.php and bind a configured hashids/hashids instance in a service provider. Keeping the settings identical across Symfony and Laravel services prevents inconsistent identifiers.
- Does upgrading to v4.0.0 change existing hashes or require a data migration?
- No. v4.0.0 changes the Symfony argument-resolution mechanism from ArgumentInterface to ValueResolverInterface; the underlying hashids/hashids algorithm, salt, minimum length, alphabet, and encode/decode output are untouched. Identifiers already persisted in URLs, database rows, or emails remain valid. There is no database migration or data backfill.
- Does roukmoute/hashids-bundle v4 support Symfony 5.4 or PHP 8.0?
- No. v4.0.0 uses ValueResolverInterface, which was introduced in Symfony 6.2, so the bundle now has a hard floor of Symfony 6.2 and therefore PHP 8.1. Services still on Symfony 5.4 LTS or PHP 8.0 must stay on the 3.1.x line and track their framework's end-of-life date.
- How should I test invalid or forged hash IDs with this bundle?
- Add integration tests for every route that uses the resolver and cover malformed, invalid, and forged hash values. The old and new resolver contracts differ in how they signal cannot resolve, resolved to null, and throw, so a shallow test can miss a change from a 404 to a 500 or an unconverted string reaching an integer-typed controller. In a Laravel equivalent, validate the decode result before using it.
- Is v4.0.0 a hard breaking change from 3.1?
- It is a hard break for Symfony versions below 6.2, but not an algorithm break. Treat the upgrade as framework alignment: bump Symfony to 6.2 or ideally 6.4 LTS first, then bump the bundle in a separate commit, remove any local overrides of the old resolver classes, and verify controller signatures that relied on the previous argument attribute. Release notes say only the mechanism changed, but confirm the public attribute name, service ID, and config keys against the diff and UPGRADE notes.
- What production risks should I consider before adopting v4.0.0?
- The biggest risk is resolver semantics drift around invalid hash input, which can turn a previously handled 404 into a 500 or pass an unconverted value into controller logic. Also note the Symfony 6.2 floor and the maintainer concentration: this is a one-contributor, one-PR major release on a small utility bundle, so there may be no backport path if a regression appears. Pin the version, test invalid input, and keep older Symfony services on 3.1.x.