- How do I install Ziggy in a Laravel app?
- Install the Composer package with composer require tightenco/ziggy, then add the @routes Blade directive to your main layout before your application's JavaScript bundle loads. No service provider registration or config publishing is required. Once the directive is in place, a global route() helper is available in your JavaScript.
- Which Laravel versions does Ziggy support?
- Ziggy is maintained by Tighten and tracks current Laravel releases, but the exact supported version matrix lives in the README and composer.json constraints on the repository. Check those before upgrading a major Laravel version in production. If you are on an older LTS, verify the constraint rather than assuming compatibility.
- How do I use Ziggy's route() helper in Vue or React?
- For Vue, install the JS package with npm install ziggy-js and register the provided ZiggyVue plugin; route() then works in templates and in script setup via injection. For React, import the useRoute hook or the route function directly from ziggy-js. Both integrations use the same route name and parameter signature as Laravel's PHP route() helper.
- Does Ziggy expose all my Laravel routes to the browser?
- Yes, by default the @routes directive embeds every named route and its parameter shape into the page HTML, which any user can view in source. That is an information disclosure surface for admin paths, internal endpoints, and feature-flagged routes. Use Ziggy's include/exclude lists, route groups, or per-page filtering to restrict what gets serialized, and treat that as a required configuration step rather than an optional tweak.
- Does Ziggy support TypeScript?
- Yes. Running php artisan ziggy:generate --types emits TypeScript declarations for your route names and their parameters. Ziggy also offers an opt-in strictRouteNames flag that turns a mistyped route name into a compile-time error instead of a runtime 404. That makes it one of the more effective guardrails against front-end link regressions when server route names change.
- Can I use Ziggy in an SPA or a separate repository from the Laravel backend?
- Yes, but with a different workflow: instead of the @routes Blade directive you run php artisan ziggy:generate to emit a config file that your front end imports. This is required when the backend route table is not co-deployed with the front end. Keep in mind the generated artifact is a build-time snapshot that can go stale, so regenerate it as part of your build or CI pipeline.
- Does Ziggy support Laravel route-model binding?
- Yes. Ziggy implements route-model binding on the JavaScript side, so you can pass a model-like object and it will resolve the correct key for the route parameter. Automatic parameter handling also covers the standard positional and named parameter forms used by Laravel's PHP route() function. This keeps your JS URL generation consistent with server-side behaviour.
- How do I test code that uses Ziggy's route() helper?
- Because Ziggy ships a Router class that accepts a configuration object, you can instantiate it directly in your test setup with a fixture route manifest instead of relying on the Blade directive. That lets you assert generated URLs in unit tests without booting a Laravel server. Wrap the helper in a thin module of your own so tests can swap in a configured Router instance.
- What is the performance impact of Ziggy with a large route table?
- The route manifest is inlined into the HTML of each page, so applications with several hundred named routes see a measurable per-response cost that repeats on every request and is not cached like a static JS chunk. Measure your serialized manifest size against your per-page budget before rolling out broadly. Filtering out routes the front end never needs is the most direct way to reduce the payload.
- Is Ziggy still maintained, and are there alternatives?
- Ziggy is a Tighten-maintained package with wide adoption across Packagist and npm, and it is the de facto standard for exposing Laravel named routes to JavaScript. The main alternatives are generating URLs from the server and passing them as props, or hand-maintaining a JS route map, both of which lose the route() parity Ziggy provides. If you use the npm package alongside the Composer package, pin and upgrade both together because they are released separately.