Wayfinder: route-name-centric API instead of controller/method mirroring?

[michaelbany]

Wayfinder currently generates TypeScript that mirrors PHP's backend structure:

import { show } from './wayfinder/PostController'
show(post.id)

This works, but it leaks backend architecture into the frontend — the consumer needs to know which controller owns which action.

I built a proof-of-concept (rosalana/safepoint) that uses route names as the single key, with TypeScript generics for props, params, and body:

// Page component
const page = usePage<PageProps<'post.show'>>()

// Navigation (generated helper fn)
route('post.show', { post: 1 })

// Form submission  
const body: RouteBody<'post.store'> = { title: '...' }

The frontend doesn't know or care about controllers — only about route contracts.

Is there intentional reasoning behind the current controller/method shape? For Inertia-focused projects especially, a route-name-centric API feels more TypeScript-native. Would love to hear the team's perspective.

Note:
I built this from wayfinder{branch:next} in a single day. It's currently just an idea. Don't take this as a production ready tool. You can clone the repo and test it out if you want to see more of it.

I might be too picky about this, but the current philosophy pushed me to build my own solution — which I don't enjoy doing when a ready-made tool already exists, built by people who are probably smarter than me.