Bug: path aliases don't get correctly resovlved in `routes.ts`

[akamfoad]

TL;DR

All imports in routes.ts and all its direct or transitive imports have to be absolute or relative using ./ and ../ notation, path aliases like ~ and @ aren't resolved correctly.

The issue

Vite and TypeScript allows defining aliases to relatively access files without using ./ or ../ notation, this is pretty significant for complex apps at scale as imports point to different, sometimes deeply nested files.

One of the usecases that inspired React Router's config-based route pattern and routes.ts was this, for example if I want to make my apps modular or feature-based, I'd use high level folders to separate features, each of these feature might export their own routes, these routes need to be imported, and for the sake of readability and consistency, we use ~ or @ symbols as relative path aliases.

Also, sometimes, we need to import variables into the routes.ts file, for example when you want to create a unique id for a route and you don't want to duplicate code and future-proof your app, this too, would be imported using an aliased path.

These use-cases aren't currently handled correctly when the routes.ts is evaluated and executed.

Please checkout the #14090 and see the bug IRL

Reproduction

1. Clone remix-run/react-router
2. Checkout akamfoad:routes-path-alias-issue branch
3. Run pnpm i
4. cd playground/framework-spa
5. Run pnpm run dev
6. You'll immediately get an error that routes.ts is invalid

System Info

N/A

Used Package Manager

pnpm

Expected Behavior

For the app to work seamlessly regardless of usage of import aliases.

Actual Behavior

Error: Route config in "routes.ts" is invalid.

[GabenGar]

Where are these aliases defined?

[brophdawg11]

I'l defer to @pcattori and @markdalgleish here if this is a bug or expected, but my hunch is that the processing of routes.ts happens as part of the processing of the reactRouter() plugin initialization and is thus before Vite has bootstrapped (and before it has processed the tsconfigPaths() plugin) so it can't understand the tsconfig aliases.

[pcattori]

I'm pretty sure that if you use package.json path aliases (rather than tsconfig.json path aliases), then TS and Vite will both use those correctly.

[akamfoad]

@GabenGar Usually they're defined in tsconfig.json at compiler.Options.paths and inside the vite.config.ts the vite-tsconfig-paths library is used which will configure the same aliases for vite, so the alias works on the type-level as well as bundler-level.

[akamfoad]

Hmmm @pcattori @brophdawg11

Package path aliases could work, but the DX is not good honestly, t'd make the config scattered across many files, the beauty of this configuration is that we have a single source of truth ( tsconfig ) and it works seamlessly everywhere.

Since React Router is just a Vite plugin, it'd be helpful if the full vite experience is supported. Aliases are an important feature for our codebase, tbh we had this issue ever since RR has become just a vite plugin, it was fine at first but it slowly became a pain, especially that there is not clear message what is exactly the issue, since the path is correctly inferred in the editor but it fails when you start the server.

Even if its not possible to add support for this feature, maybe let's keep this open or add it to the roadmap and work on it in the future.

[GabenGar]

@akamfoad

Usually they're defined in tsconfig.json at compiler.Options.paths and inside the vite.config.ts the vite-tsconfig-paths

Off to a great start with usually for something precise like module specifier resolution. What about unusual setups?
tsconfig.json by the way is not a real json file, it's more of a jsonc, so the standard JSON parser will choke on it. This config file can also extend from other config file which can extend from other config file... so the entire typescript config resolution procedure has to be ran just to get the paths.
vite.config.ts is not a javascript file, which means it has to be compiled by typescript first, exactly what the current vite setup does. Where does the config for this process come from? Do note it should also accept vite.config.mts, vite.config.cts, vite.config.mjs, vite.config.cjs and vite.config.js files and vite.config.js/vite.config.ts must also compile according to the value of "type" in package.json.
Even better, since it's a javascript file (in the end at least), it can have an unlimited amount of side effects to run before even getting to actual config. But also it depends on a specific plugin present and be added to the final config.
There isn't even a standard way to define aliases, the current ones:

• ~ - a bash-only alias for home directory (doesn't make sense outside of unix-like terminal environments)
• @ - a prefix reserved for scoped packages on npm

only persisted because some guy put them into a starter template and it propagated.

but the DX is not good honestly, t'd make the config scattered across many files

How is looking up package.json, a file in spec-compliant format and finite size, more "scattered" than parsing at least 2 files with vague rules and potentially infinite resolution time? Note that looking up package.json is required for parsing those files in the first place.

RR has become just a vite plugin

Citation needed. As per these blogposts: React Router and React Server Components: The Path Forward and Wake up, Remix!, RR will either become bundler-free or Django.

[timdorr]

@GabenGar That kind of discussion isn't really productive to the conversation here. This is simply a matter of routes being allowed to use TS to resolve modules, which may be an impossibility with the current plugin architecture. Let's keep it to just that.