Issues with isolatedDeclarations and the associated fixes in editor #58426

🔎 Search Terms

isolatedDeclarations, quickfix, lag, editor, VSCode, 5.5

🕗 Version & Regression Information

• This is specific to new 5.5 features

⏯ Playground Link

No response

💻 Code

_

🙁 Actual behavior

I've been testing out isolatedDeclarations in VSCode Insiders on WSL and wanted to collect a few of the issues I noticed in general, especially with some of the associated quick fixes as discussed with Jake Bailey (@jakebailey) in the TS Discord.

1. The most egregious issue I encountered was a huge lag spike when calculating quick fixes for isolatedDeclarations, even for simple types.

Here you can see I can hover this.to?.traverseApply which is trivially inferred as a simple type from the base class. But then after I hover outValidator and it has to generate a quick fix, it's like it gets stuck recalculating it:

2. I also notice when I'm annotating a value with an isolated declarations error, sometimes auto import suggestions can take several seconds to pop up, so it seems like a general performance issue with some of these fixes.

More broadly, I also notice the total check time for ArkType's repo has increased from 7.5 seconds in 5.4 to 9.5 seconds in 5.5, so there may be some underlying change to e.g. calculate additional predicates, but these fixes associated with isolatedDelcarations seem to be particularly problematic.

Another pattern I noticed was lots of inline imports when applying a quick-fix which is rarely desirable. It would be great if by default (e.g. if there are no naming conflicts), the import would be added to the top of the file and the type would be referenced as normal:

3. I use the pattern type SomeType<parameter = SomeDefault> frequently, and I notice whenever a quickfix is applied it adds the parameter even if it's the default.

This wouldn't be a huge deal, but since if SomeDefault is a type, it will also be expanded out to its structural form and potentially inline-imported, it can add a ton of visual clutter (sometimes an order of magnitude more than the type itself).

4. I don't understand well most of the underlying rules but I think my biggest wish for isolatedDeclarations is more constants like those strings initialized as class props or stuff like this could somehow not require duplicating the entire object structure at a type-level to replicate what typeof someConstant could do in the past:

If that's fundamentally in conflict with the goals of --isolatedDeclarations, feel free to disregard, it just feels frustrating to have no way to derive the type and value from a single source without repeating them anymore even for simple cases.

Sorry for the haphazard format of this issue. I'm very excited about this feature as some of these kinks are ironed out I think the fixes will also add a lot of value, I just wanted to make sure there was a record of these things, particularly since Jake requested I submit something.

🙂 Expected behavior

_

Additional information about the issue

No response