Typesafety improvements #12019

pcattori · 2024-09-19T23:08:57Z

See the included decision doc

TODO

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 · 2024-09-19T23:09:01Z

🦋 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

so that we can reuse this for typescript plugin

brookslybrand

Feedback on "Type inference" decision doc

decisions/0012-type-inference.md

brookslybrand · 2024-09-23T14:34:12Z

decisions/0012-type-inference.md

+   > But in the initial SSR render, the `clientLoader` doesn't run, so really you'd need `typeof loader | typeof clientLoader`.
+   > Unless you also set `clientLoader.hydrate = true` _AND_ provided a `HydrateFallback`. Then `clientLoader` always runs so you'd want just `typeof clientLoader`
+
+   That `useLoaderData` generic starts to feel a lot like doing your taxes: there's only one right answer, Remix knows what it is, but you're going to get quizzed on it anyway.


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

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

decisions/0012-type-inference.md

david-crespo · 2024-09-23T19:56:58Z

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 · 2024-09-23T20:13:58Z

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 · 2024-09-23T21:36:05Z

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 }; 
        
           }

playground/compiler/tsconfig.json

decisions/0012-type-inference.md

github-actions · 2024-11-22T07:48:23Z

🤖 Hello there,

We just published version 7.0.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

github-actions · 2025-01-14T16:07:46Z

🤖 Hello there,