Disable JavaScript "guess work" when using TypeScript?

Answered

In JavaScript IntelliJ does a lot of intelligent guessing to do things like find declarations, references, refactoring, etc. Sadly it's often wrong, because JS is dynamic there's a lot of guessing that has to be done. But in TypeScript there's no guessing. However I've noticed that IntelliJ seems to still use a lot of JavaScript guess work when doing those things in a TypeScript project, and it's often wrong, just adding noise. Can the JS guessing be turned off completely? For example if I refactor a TS interface property name I find that IntelliJ will replace wrong things simply because it has the same name, sometimes even in strings or other completely wrong places. I know in JS this might be a good start, but in TypeScript it's quite frustrating because there's no need for all the extra guessing. TypeScript compiler knows the truth, I just want to stick with that. I actually find it's often easier and definitely more reliable to NOT use the IntelliJ refactoring abilities and instead make a change and let the compiler highlight everywhere I need to change, and manually change them. 

7
7 comments

No, it can't be disabled, and we have no plans to disable it completely, it just can't be fully replaced with the functionality provided by tsserver as the latter is not as feature rich, doesn't provide all needed APIs, etc.  In the future, we do plan to replace some of our refactorings with the ones coming from language service, but this doesn't concern to _all_ refactorings

 

>For example if I refactor a TS interface property name I find that IntelliJ will replace wrong things simply because it has the same name, sometimes even in strings or other completely wrong places.

do you have Search for text occurrences and Search in comments and strings enabled in Rename dialog?

-1

Hm. That's a bummer. I'm not sure what limitations TSServer have but my real complaint here is that JS guessing is just wrong, when TSC is right. Yes, I avoid "Search for text occurrences", but that's just one example. Another is this trivial code:

import styles from "../components/app/portfolio/projects/ProjectsTable.css";

Type definitions for that file looks like this:

export const visible: string;
// ...

Now if I mouse over a reference to `styles.visible` I get this wrong documentation (where does it even come from?):

And if I click to go to source of `styles.visible` I'm given tons of random and completely wrong choices, seemingly everything in my codebase that is called "visible":

The TypeScript compiler has no problem with this. It knows exactly what `styles.visible` is and where it comes from, as shown in any compile error messages.

So if by "can't be fully replaced by the functionality of tsserver" you mean give me tons of incorrect feedback, I would be happier without it. 

3

Agreed with Aaron. When I use 'Find Usages' function for a class field with a simple name (i.e 'type') in my pure typescript project, Webstorm first searches for a long time and then shows me 30 dynamic usages along with typescript usages.
I absolutely don't need those. Just showing me only typescript usages would cover 100% of my needs.

Please consider adding a setting to disable dynamic usages. They ruin performance and add a lot of noise.

1

+1 to this as well. The guesswork in TypeScript projects at best is just some additional noise, at worst causes errors/warnings where none should be present. Being able to disable these and rely entirely on type/import based data would be ideal.

0

This has nothing to do with using Typescript language services or not (that's an implementation detail), it's about not indexing or searching Javascript files in the first place.

If I could just limit the scope of where WebStorm looks for the whole project rather than per popup window that would be great.

I've also always found having the default be the most dangerous setting possible pretty crazy (just try renaming a something called "get" or "value" in any of JetBrains products with default options and say goodbye to your source code)

It's the very first thing I always tell people to do before they use any of the refactoring tools in any of your tools.

Principle of least surprise and all that

 

0

Any update regarding this? It would be quite useful.

0

I also find this frustrating. I have absolutely no need whatsoever to index javascript files. has there been any progress on this? 

4

Please sign in to leave a comment.