Fix various TypeScript issues, simplify ziggy-js integration and shared props usage

[TimKunze96]

This pull request simplifies type usage, removes unused imports, and improves the SSR setup.

Ziggy-JS

While following the Ziggy-JS setup guide, I noticed that our ssr.ts file does a lot of unnecessary work. We can replace most of it with the ziggyVue plugin. We also don’t need the Ziggy alias pointing to the vendor directory, since Ziggy is already installed as a JS dependency. Finally, I added proper Vue-specific route definitions.

TypeScript Types

• SharedProps: Refactored to extend and override the package’s App props, so we can use the usePage helper without manually declaring prop types each time.
• Inertia helpers: Added missing type definitions for Inertia helper functions used in template files.
• tsconfig.json: Removed the non-existent vue/tsx entry from the types array. It wasn’t provided by any installed package and caused errors during vue-tsc type checks.

[TimKunze96]

Continuation of #87

[Plytas]

Maybe we should go ahead and use wayfinder instead of ziggy?

[TimKunze96]

I plan to switch to Wayfinder once it’s stable, but given Ziggy’s long history of being preconfigured in the starter kits, I think it should remain available—perhaps as an install-time option?

[Ciaro]

Thanks for this, Tim! While we are on the subject of Ziggy: is there a specific reason why all the Ziggy routes are a part of the Inertia shared data as well? The routes are already part of the page via the global Vue configuration, no?

[TimKunze96]

As I understand it, this is necessary because the SSR script doesn’t have access to the Blade file’s contents. When the server renderer tries to read the routes that the Blade file would normally declare, it fails. The client-side script works fine, however, because by the time it executes, the routes have already been declared and are available in the browser.

That’s why we need to pass the routes via shared properties. Technically, this should only be necessary in the initial, server-rendered response. If an X-Inertia header is present on subsequent requests, we could skip that step, if I’m not mistaken.

This discrepancy has been a real pain point for me in the past—SSR errors (for example, accessing document or window) are easy to overlook during development if the client-side script still runs without issue.

Edit: While digging a little bit deeper I stumbled across those posts, basically all outlining the same problem:

https://github.com/tighten/ziggy/discussions?discussions_q=is%3Aopen+ssr

This post basically ends up with what we have now I believe
tighten/ziggy#564

[Ciaro]

Really appreciate the thorough explanation, Tim!

I won't be using SSR any time soon, so I just removed the sharing of the Ziggy routes in Inertia and replaced the one reference to it (resources\js\layouts\settings\Layout.vue) with a reference to the page.url parameter Inertia already exposes:

const currentPath = new URL(page.props.location).pathname;

becomes:

const page = usePage();
currentPath = page.url;