Improve Ziggy setup in Inertia stacks #340
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ziggy maintainer here 👋🏻
This PR improves Ziggy's typings in the Inertia stacks and removes some unnecessary code.
Since v1.8.0 Ziggy ships its own types, so the
@types/ziggy-js
package is no longer needed. The types are included in thetightenco/ziggy
Composer package; the changes tojsconfig.json
andtsconfig.json
allow them to be picked up from there.The global
Ziggy
object being passed in.use(ZiggyVue, Ziggy)
in the Vue stacks isn't necessary (it's made available globally by the@routes
Blade directive) so I removed it. Without that, there are no references to that global object out of the box in any stack (and it's uncommon to reference that object directly), so I also removed the global type declaration for it.The shared
ziggy
data in theHandleInertiaRequests
middleware is only needed for SSR, so I removed it by default and added a step to the install command to insert it if that option is enabled. I also added a step there to include TypeScript type information corresponding to that shared data, so thatpage.props
includesziggy
and it's typed correctly. This let me remove a couple of// @ts-expect-error
comments too (but only for Vue, because the React stacks don't merge their own Inertia page prop type declarations into the global ones). The text replacements in this new method are pretty ugly I know, I'm happy to change that up however you think is best. I went down the road of adding alternate versions of those files first, but eventually came back this way because it would have been so much duplication.I tested these changes by manually creating 8 new Laravel apps and setting up Breeze with every possible combination of Inertia React, Inertia Vue, JavaScript, TypeScript, SSR, and no SSR, and making sure they all scaffold the expected files and build successfully, which they do! Anecdotally, in VS Code, the intellisense around the
route()
function and other Ziggy stuff is much better now too.This shouldn't be a breaking change because it will only affect new Breeze installations. Let me know if you have questions!