Typesafety improvements

[pcattori]

See the included decision doc

TODO

• typegen CLI
• fix react-router/dev/routes resolution error
• rename args/props type utils to be different than the typegen'd type names
• typegen consistent with route files, not just routes.ts config (delete typegen'd file when route no longer exists)
• clientLoader hydrate API
• .d.ts instead of .ts for typegen'd files
• typegen for root route
• no hardcoded app/ dir
• decision doc reject solutions: tsplugin, defineLoader + friends
• changeset

Follow-on work

• typegen: headers, links, meta, shouldRevalidate, handle, etc.
• plugin: autocomplete for route exports
• plugin: jsdoc for route exports
• plugin: HMR warnings

[changeset-bot]

🦋 Changeset detected

Latest commit: 7e87c5d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
@react-router/dev	Major
react-router	Major
@react-router/fs-routes	Major
@react-router/remix-config-routes-adapter	Major
@react-router/architect	Major
@react-router/cloudflare	Major
react-router-dom	Major
@react-router/express	Major
@react-router/node	Major
@react-router/serve	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[brookslybrand]

Feedback on "Type inference" decision doc

[brookslybrand]

I wonder if this is a universal experience or more US-centric 😅

[jvzaniolo]

I can confirm that in Brazil it's exactly like that too

[david-crespo]

Looking forward to this feature. I enjoyed reading the decision doc. I wasn't familiar with TS LSP plugins, so I looked them up and found this in the TS wiki:

TypeScript Language Service Plugins ("plugins") are for changing the editing experience only. The core TypeScript language remains the same. Plugins can't add new language features such as new syntax or different typechecking behavior, and plugins aren't loaded during normal commandline typechecking or emitting, (so are not loaded by tsc).

If this is true, then it seems like a big downside of the plugin approach that's worth addressing. If it is not true and tsc on the command line will turn up type errors from the generated types, then that would be worth mentioning as well. When I saw LSP plugin, I immediately wondered how it will work on the command line.

Edit: Ok, and that's why you don't comment on work in progress:

react-router/decisions/0013-zero-effort-typesafety.md

Lines 79 to 87 in 2d5e406

	2. **TypeScript plugin do not affect typechecking**
	TypeScript does have [language service plugins](https://github.com/microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin),
	but these plugins can only augment the experience in your editor.
	In other words, these plugins do not get used when `tsc` to typecheck your code.
	Relying solely on your editor to report type errors is insufficient as type errors can easily slip through.
	For example, you could edit one file and cause a type error in another file you never opened.
	To ensure this never happens, typechecking needs to be a standalone command runnable by CI.

[pcattori]

Looking forward to this feature. I enjoyed reading the decision doc. I wasn't familiar with TS LSP plugins, so I looked them up and found this in the TS wiki:

TypeScript Language Service Plugins ("plugins") are for changing the editing experience only. The core TypeScript language remains the same. Plugins can't add new language features such as new syntax or different typechecking behavior, and plugins aren't loaded during normal commandline typechecking or emitting, (so are not loaded by tsc).

If this is true, then it seems like a big downside of the plugin approach that's worth addressing. If it is not true and tsc on the command line will turn up type errors from the generated types, then that would be worth mentioning as well. When I saw LSP plugin, I immediately wondered how it will work on the command line.

Edit: Ok, and that's why you don't comment on work in progress:

react-router/decisions/0013-zero-effort-typesafety.md

Lines 79 to 87 in 2d5e406

	2. **TypeScript plugin do not affect typechecking**
	TypeScript does have [language service plugins](https://github.com/microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin),
	but these plugins can only augment the experience in your editor.
	In other words, these plugins do not get used when `tsc` to typecheck your code.
	Relying solely on your editor to report type errors is insufficient as type errors can easily slip through.
	For example, you could edit one file and cause a type error in another file you never opened.
	To ensure this never happens, typechecking needs to be a standalone command runnable by CI.

For onlookers: its worth calling out that everything in this decision doc (#0012) keeps typechecking working as expected. The only things proposed in #0012 are automatically running typegen in watch mode and adding some editor DX features. As you point out (#0013) is where this limitation of TS plugins is relevant.

[david-crespo]

I think what threw me off is that the first paragraph of the Typegen section makes it sound like typegen is primarily about file-based route config.

react-router/decisions/0012-type-inference.md

Lines 161 to 166 in 624093f

	### Typegen
	While React Router will default to programmatic routing, it can easily be configured for file-based routing.
	That means that sometimes route URLs will only be represented as file paths.
	Unfortunately, TypeScript cannot use the filesystem as part of its type inference nor type checking.
	The only tenable way to infer types based on file paths is through code generation.

But from doc 13 it sounds like the language service is still leveraging the typegen directory behind the scenes for programmatic routing, you just don't have to annotate the route exports yourself.

react-router/decisions/0013-zero-effort-typesafety.md

Lines 119 to 128 in 2d5e406

	And the language service will make sure the typechecker sees this:
	```tsx
	// app/routes/product.tsx
	// URL path: /products/:id
	export function loader({ params }: import("./+types.product").loader["args"]) {
	const user = getUser(params.id);
	return { planet: "world", user };
	}

[markdalgleish]

The decision doc is really nice 👍