Expose path aliases extracted from tsconfig.json and package.json

[brillout]

Extracting the path alias information defined by tsconfig.json#compilerOptions.paths and package.json#imports isn't trivial. For example if the user has multiple tsconfig.json files.

It could make sense if the path alias information, which Rolldown needs to extracts from tsconfig.json and package.json anyways, is publicly exposed for tools built on top of Rolldown such as Vite.

If Vite uses that information, then Vite users won't have to define path aliases redundantly in vite.config.js anymore. Making vite-tsconfig-paths obsolete.

[hyf0]

Thanks for bring this up. So far we could tell is that rolldown provided the ability of aliasing, but for

Extracting the path alias information defined by tsconfig.json#compilerOptions.paths and package.json#imports isn't trivial. Most notably if the user has multiple tsconfig.json files.

we need to evaluate if this should be done by a bundler itself or an upper level tools.

[brillout]

FYI esbuild does it (but I don't how complete it is). I see, I guess an alternative would be Rolldown accepting a path alias parameter (albeit less correct since it'd be global and couldn't account for multiple tsconfig.json), or a hook like onResolve() (although I'm not sure how a JS-land onResolve() would slow down everything) 🤔

[hyf0]

Yeah. I know esbuild does it. So far we can tell we would provide resolve.alias ability for cutomization.

However, whether to built-in support tsocnfig.json is still undecided due to something are not think through. Such as the priorities/conflicts of tsconfig.json and resolve.alias. Alll these things would be more complicated if we also consider package.json#imports.

[brillout]

Indeed it seems quite complex as jwnx pointed out.

Maybe Rolldown could, at first, have only rudimentary support that users can opt-out, and then grow from there without breaking changes since, in principle, making Rolldown more correct isn't a breaking change.

A rudimentary support could maybe be something like that:

• Pick up tsconfig.json#compilerOptions.paths if and only if tsconfig.json lives at the root. Apply it only to TS files, and only to those included by the tsconfig.json configuration (not sure how complex that can be).
• Pick up package.json#imports and only apply it to JS files.

I presume the (vast?) majority of users define path aliases only once and in a global fashion (TS users once in tsconfig.json and JS users once in package.json#imports). Maybe there is a way to support this use case in a (relatively) simple way. Maybe even forgoing the capability for the user to opt out if there is confidence the implementation to be correct.

[jwnx]

I believe the main benefit of using vite-tsconfig-paths or providing a resolve.alias is demonstrating the user's wish either for vite to look for a tsconfig.json or to use a specific alias configuration, as opposed to esbuild's forcibly looking for a tsconfig.json file position. We should pay attention to their discussion at evanw/esbuild#3019 because most issues were addressed at length, but I cherry-picked some issues esbuild faced related to our discussion so far:

• Reconsider reading from multiple tsconfig.json files evanw/esbuild#402
• Tell esbuild not to load tsconfig evanw/esbuild#2440
• esbuild improperly follows tsconfig.json paths, causing duplicated imports evanw/esbuild#2386
• resolve hook doesn't respect tsconfig's compilerOptions evanw/esbuild#2265