WebStorm 2019.2 EAP #5: improvements for the Rename refactoring and type hints

WebStorm 2019.2 Early Preview build #5 is now available!

If you’re unfamiliar with our Early Access Program or if you want to catch up on all the new features, check out the previous EAP blog posts.

The Toolbox App is the easiest way to get the EAP builds and keep both your stable WebStorm version and any EAP versions up to date. Or you can download the EAP builds from our website. You can also get notified right from the IDE when a new EAP build is available: go to Preferences | Appearance & Behavior | System Settings | Updates and select “Automatically check updates for Early Access Program”.

DOWNLOAD WEBSTORM 2019.2 EAP

Important! WebStorm EAP builds are not fully tested and might be unstable.

Here are some of the highlights of WebStorm 2019.2 EAP #5 (build 192.5438.26). For the full list of issues fixed in this update, see the Release Notes.

Improvements for the Rename refactoring

In this update, we’ve made some changes in the way WebStorm performs the Rename refactoring in JavaScript and TypeScript. The most significant of which is, that now, the usages that the IDE treats as dynamic are not renamed by default and they are grouped together in the Refactoring preview and Find Usages tool window.

Because of the dynamic nature of JavaScript, there could be cases where a dynamic reference is actually a valid usage and should be renamed, but from your feedback, we’ve found that in a lot of cases the refactoring was renaming the symbols too aggressively and it wasn’t the desired or expected behavior.

Here’s an example with TypeScript:

Previously, e.target was also renamed automatically because e has the type any meaning it could also be myInt. Now, there’s a new option Search for dynamic references in the rename dialog that is unchecked by default, thus, the dynamic usages are not renamed. If you check it, you can then click Preview to review the results and decide which of them you want to be renamed.

Rename dialog

In JavaScript code, you will now always see the Preview window before a more complex refactoring that includes not only local variables will be performed.

Another recent change we’ve brought in is the scope selector in the dialog. With it, you can limit the scope of the refactoring.

If you’re experiencing any problems with the refactoring, please let us know by reporting an issue on our tracker. We would really appreciate it.

Type hints in the editor

You might already be familiar with parameter hints – the tiny little hints next to a parameter in a function call which show you the name of the parameter from the function definition.

In WebStorm 2019.2, we are adding new types of hints – one for return types and one for variable types.

By default, you will see the return types for chained methods that are split between multiple lines and return at least 2 different types. It works in both JavaScript and TypeScript.

type-hints-chained-methods

WebStorm infers the type information from a JSDoc comment or based on the static analysis of your code.

There are also type hints that will show you a variable type or a function return type next to their definition (and look like the type annotations in TypeScript). These hints are currently turned off by default, but we are planning to enable them in the future. You can turn them on yourself in Preferences | Editor | Inlay Hints | JavaScript or TypeScript | Type hints: Show for variables, parameters, and fields and Show for function return types.

type-hints-annotations

In TypeScript, there are also hints for enum values.

Hide frames from libraries in the debugger

The filter icon in the debugger Call stack panel now works more accurately. It allows you to hide all the calls from 3rd-party code (e.g. project dependencies in the node_modules folder, Node.js Core modules, or code related to the module bundler).

hide-frames-from-libraries

This mechanism works on top of the JavaScript Libraries feature in WebStorm, so basically everything that is marked as a library in Preferences | Languages & Frameworks | JavaScript | Libraries will be hidden. The frames from the library code are also marked with a yellow background.

Please report any issues on our issue tracker. And stay tuned for the next week’s update!

WebStorm Team

About Ekaterina Prigara

Ekaterina Prigara is WebStorm product marketing manager at JetBrains. She's passionate about new technologies, UX and coffee.
This entry was posted in Early Access Preview and tagged , , . Bookmark the permalink.

17 Responses to WebStorm 2019.2 EAP #5: improvements for the Rename refactoring and type hints

  1. Edoardo Luppi says:

    Could the same concept of refactoring be applied to the find usages to me (example, CTRL+Click on an element)? In case I’ll open an issue on YouTrack, if there is no others.

    • Edoardo Luppi says:

      Ops, “to me” shouldn’t be there. Btw, is there a way to delete our comments?

    • Ekaterina Prigara says:

      Hi Edoardo,
      Find Usages now also has this new group called Dynamic usages but not the Go to definition action. I’m not sure we want to limit Go to definition like that because it’s directly related to resolving symbols.

      • Edoardo Luppi says:

        Yeah sorry. I meant the Go to definition (CTRL+Click).
        Sometimes I have TS > JS build folders which I’d like to definitely exclude from indexing, but I cannot because Gradle keeps re-importing the project each start-up, and they’re defined there for some reasons.
        When I use Go to definition the references in the build folders are also picked up, and usually I see dozens of them in the dialog before the actual TS ones, with mangled file names too, totally unneeded.
        I will post an screenshot link here as soon as I can, but I hope I was understandable.

      • Edoardo Luppi says:

        I know I can define custom scopes. But a set custom scope gets reverted to Project files each re-start.

      • Edoardo Luppi says:

        Here is screenshot with the entries I’d like to exclude, but I actually cannot.
        https://i.postimg.cc/0j6xrMSj/Screenshot-20190701-100444.png

        • Ekaterina Prigara says:

          Do you have this directory with the generated code listed in tsconfig.json under excluded?

          • Edoardo Luppi says:

            Yes, in the form of “exclude”: [“build”].

          • Edoardo Luppi says:

            I also that directory specified in the build.gradle file, as
            war {
            webAppDirName = “${project.buildDir}/www/”
            }

          • Ekaterina Prigara says:

            Sorry, forgot to ask: is it specified as “outDir”, right?

          • Edoardo Luppi says:

            No, it’s not specified in “outDir” of tsconfig.js. But it is specified in the “outputPath” of the angular.json file.

          • Ekaterina Prigara says:

            Thanks for the details. We’ll see how we can improve the behavior is this case. Thanks!

          • Edoardo Luppi says:

            Maybe let us users exclude folders also overriding the Gradle build configuration. That’s the problem, Gradle always override what I specify in the exclude patterns, after each restart.

  2. Jiří Švec says:

    Unfortunately doesn’t work force touch for navigation to declaration, but force touch is detected as normal click ;-( Use Mac

  3. Victor Vincent says:

    The change for searching filenames have changed for the worst recently. Previously I could have the search term like ‘po i’ and it was showing the Posts/index.js file. Now thats nit working, have search fir folder name, double-click, search open tree, double-click file. Too much extra work.

    I also really hope module resolution will work fine with the index-reexport pattern. If I do import stuff in index.js, reexport them and at the place of usage CTRL+Click, it’ll only jump to the top of the file to the import and to it’s definition. What is magic that it works fine 1 out of 10 times…

    • Ekaterina Prigara says:

      Hello,
      Can you please share a bit more details about the search problem? Where exactly do you search – in the Project view, or in the Go to File popup, or using Search Everywhere?

      We would really appreciate it if you report an issue about the module resolution on https://youtrack.jetbrains.com/issues/web. Please attach a sample project showing the case when it doesn’t work, as well as the description of the expected behavior. Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *