Use LazyBarrel to improve IDE performance

[mgfalzon]

🔍 Search Terms

"re-export", "barrel file", "optimization", "performance"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Can the Typescript Language Server implement and use its own version of the LazyBarrel optimization as an experimental feature to improve IDE performance?

📃 Motivating Example

This feature should improve IDE performance (e.g. type highlight) and reduce the impact of barrel files on Typescript codebases.

Explanation provided on LazyBarrel.

💻 Use Cases

1. What do you want to use this for?

Improving IDE performance.

2. What shortcomings exist with current approaches?

Barrel files have a significant impact on IDE performance in Typescript codebases.

3. What workarounds are you using in the meantime?

Manually de-barreling packages.

[DanielRosenwasser]

This is mostly just me thinking out loud - we've talked about a version of this over and over throughout the years and the problem is that:

1. For a build, you want the errors of every file in your project anyway - for --incremental, we are smart enough to avoid this work a lot of the time anyway by avoiding re-checking unchanged dependencies.
2. For the language service, functionality like auto-imports and find-all-references expects to be able to have enough of the program to work off of anyway. In fact, auto-imports wants more than just your program - it wants to process imports you might want to load eventually.
   1. You can shorten "time to interactive" - the time until we can respond meaningfully to a request - this is what we do in 6.0 and earlier with an "only open files" language service until the full one loads. In 7.0, we plan to lazily load un-imported dependencies for auto-imports (I think up until completions or diagnostics is requested) . But loading the entire program has been so fast in the native port that we may simplify the model here.

From an architectural point of view, we try to keep the checker from introducing new "program state" - for example, introducing new files (maybe the checker could have its own "overlay" program, but the containing program could share a cache with it?). There's not exactly a reason we couldn't do this otherwise though - I think we have pretty explicit points of indirection in the checker to load files lazily.

I'm sure for a lot of developers, a mode like this might still be useful - likely in really large repos. Right now we're focused on just porting 7.0, but we'll still be open to thinking about these problems after.

[mgfalzon]

Got it. Thanks for the speedy and informative response @DanielRosenwasser !!

I'm sure for a lot of developers, a mode like this might still be useful - likely in really large repos.

For context, at Atlassian we have seen:

• De-barreling of Confluence Frontend led to a 27% decrease in P75 type highlight duration (20s -> 14s)
• De-barreling of Jira Frontend led to a 30%+ decrease in type highlight duration (don't have exact numbers)

We are considering de-barreling our component library (the real issue for our monorepo), but will wait until we migrate to tsgo! Looking forward to seeing the improvements in this area after migrating!