Announcing WebStorm 2019.2 roadmap

It’s been over a month since the WebStorm 2019.1 release, we are done (almost!) with the bug fixes and we are now starting work on the new features and improvements for the WebStorm 2019.2 release, which is scheduled for the end of July.

We will start the Early Access Program for WebStorm 2019.2 in the next couple of weeks. In the meantime, we would like to share with you our roadmap for WebStorm 2019.2. This is something we haven’t done since the end of 2015, when we moved to having three major releases a year.

The main goals for the upcoming release are:

  • Boost productivity when working with JavaScript and TypeScript with smart intentions, quick-fixes, and refactorings.
  • Make the Vue.js support better.
  • Improve performance, quality, and usability of the existing features.

Here’s a more detailed overview of the things the WebStorm team will focus on for the 2019.2 release:

JavaScript and TypeScript

  • New intentions around destructuring.
  • New control-flow-based inspection and intentions.
  • Improve the Rename refactoring:
    • Do not rename dynamic references by default.
    • Investigate how we can improve the UI and UX of the refactoring preview (e.g., better grouping for usages).
  • Improve the presentation of completion suggestions: remove excessive information, make it more consistent and clear.
  • Better support (including formatting) for template strings with injections of other languages.
  • Support for the upcoming TypeScript releases and ECMAScript proposals.


  • Improve Vue.js support:
    • Cleanup and refactoring in the core Vue.js support.
    • Support for the slot syntax.
    • Investigate how we can provide better support for the popular UI component libraries.
  • Create new React components from unresolved usages.
  • Prepare for the upcoming Angular 8 release.


  • Code completion in JavaScript configuration files for ESLint, Babel, Prettier, and others.
  • Investigate nvmrc support.


  • Improve presentation of DOM elements in the debugger console.
  • Blackbox library/framework calls in the debugger.


  • Option to open another project in the current IDE window.
  • Investigate support for the JavaScript tooling in the Run Anything popup.

This plan includes some bigger tasks and features we are planning to work on in the development cycle for WebStorm 2019.2. It doesn’t include smaller improvements and bug-fixes we are going to implement. And of course, we have put some time aside for on-going performance and stability improvements.

We will be listening to your feedback and keeping an eye on the changes in the ecosystem and adapt our plan if needed.

We have about 6 weeks of active development ahead, with weekly EAP builds before the feature freeze that will happen about 4 weeks before the release. Some features might need to be moved to the next release.

We also expect a lot of improvements to come from the IntelliJ IDEA platform (as you might know, WebStorm is built on top of this platform; things like support for VCS, editor, and the UI in general, are part of IJ platform and developed by the IJ platform team).

If you have any ideas for a new feature or you would like to share your feedback with us, please file an issue on our tracker. We’re listening!

Stay tuned!

The 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 General Announcements and tagged , . Bookmark the permalink.

26 Responses to Announcing WebStorm 2019.2 roadmap

  1. Edoardo Luppi says:

    There is a thing I don’t understand: the “Redundant else” check (and some others) is under Intentions in JS/TS, but it is under Inspections for Java. This means for JS/TS there is no hightlight of the “problem”. Is this something done on purpose?

    • Edoardo Luppi says:

      Also, something that might be useful is a better integration with Prettier, which is used a lot now. As of now I have to use IDEA/WebStorm to remove/order imports and then use the Prettier plugin’s shortcut to reformat code. Maybe if a user has installed the Prettier plugin this should be done in a single step, with the Prettier formatting overriding the IDE one. It’s something that seems small but it has a big impact for who reformat a lot.

      • Harrison Heck says:

        I absolutely agree that if prettier is installed, it should be used for the formatting. This is how it works in VS Code as well. It’s a PITA to have to use a different shortcut key just for prettier.

        • Edoardo Luppi says:

          The plugin is open source, I will give a look at how it’s done and if it possible to override the behavior, for my knowledge mostly.

  2. Rasheed Rahman says:

    I’ve used phpstorm and there’s this tiny feature I love.

    it’s called ”run anything”

    please bring it to webstorm, thanks

  3. sG says:

    I’m glad Improve the Rename refactoring is on the list because right now its completely broken and the #1 reason why I still use VS Code even tough I have Webstorm.

    • Ekaterina Prigara says:

      We do plan to work on some general improvements, but we would really appreciate it if you share with us some examples when you had problems with the rename refactoring. Thank you!

      • Jos Warmer says:

        E.g. when using yarn workspaces with TypeScript. See Will this be fixed as well? Would be great!

        • Ekaterina Prigara says:

          Thanks for the link! This is a rather complex issue because in case of workspaces resolve works via the generated .d.ts files which should be updated by the build tool and not the rename refactoring. We’ll try to find a way to work around that.

      • SG says:

        Here is one example: if you refactor Shift-F6 the property “target” inside IFoo it will also refactor which will break the code.

        interface IFoo {
        propOne: string;
        propTwo: number;
        target: string;

        const Component = ({propOne}: IFoo) => (

        const eventHandler = (e) => console.log(;

        • SG says:

          In short, it looks like when WebStorm is not 100% certain which type a variable is it will refactor anything that “looks” the same even if in fact its not the correct type. And it doesn’t even show the “refactor preview” screen to let me unselect those.

          In my exampe if you change the last part to include a specific type for “e” it works correctly const eventHandler = (e: IEvent) => console.log(;

        • Ekaterina Prigara says:

          In this case e has type any and WebStorm treats it as a dynamic reference. As we’ve mentioned in our roadmap, we plan to disable renaming dynamic references by default.

      • SG says:

        Ekaterina here I got another example I just found happing today (bad2.tsx in the repo). It seems like “Dynamic references” is what causes the problems. Webstorm is making too many changes (trying too hard to fix all the renames even when its not 100% sure). I would rather have it change less stuff automatically and have to go through the code to fix one or two problems that what it does right now because right now if I ever refactor a variable called something really common like “id” Webstorm will literally change HUNDREDS of my files anywhere the word “id” comes up. Sometimes it feels almost like Webstorm is doing a full search/replace of the word “id” instead of a smart refactor.

        • Ekaterina Prigara says:

          As a workaround, please exclude the dynamic references from the refactoring in the Refactoring preview window – select the Dynamic references node and press Delete:

      • Ben Babic says:

        Here is a bunch of related ones that force me to use VS Code to navigate most of my codebase but there seem to be no progress or communications on the tickets for quite a long time:

        • Ekaterina Prigara says:

          Hello Ben, thanks for your feedback. We plan to look into these issues when working on improving the refactoring. Sorry for the inconvenience it caused.

  4. Alex Vorbau says:

    I frequently use a Mac app called RunJS. It’s great for bench-testing snippets of code. I can include common libraries such as lodash and moment. Perhaps you have something like this in WebStorm already and I haven’t discovered, but it would be a great addition to the product.

  5. John says:

    Are there any plans to support Yarn PnP? I have not found any information that it is supported and when I tried to use it, Webstorm always highlighted packages as not installed.

  6. Moonface says:

    I am so glad to see TypeScript improvement.
    Is there a chance to support TypeScript as JSDoc format in JavaScript files?
    Currently VSCode support TS as JSDoc really well. But WebStorm is not able to do auto-complete/refactor based on JSDoc annotation. Also it shows some false negative warning for some JSDoc annotation.

    • Ekaterina Prigara says:

      Can you please explain a bit what you mean? A sample project would be very helpful.
      WebStorm supports JSDoc comments in JavaScript files and uses type information from it for code completion and code quality analysis. For example, it will warn you if you use a different type of function parameter.

      • Moonface says:

        Thanks for the reply.
        TypeScript supports JSDoc type declaration in JavaScript files as documented in

        The WebStorm support JSDoc comments, but it does not cheat those comments as valid TS annotations even if the .js file start with //@ts-check.
        The following gist shows a sample React component with JSDoc annotation:

        When the Header component is used elsewhere in the project, the WebStorm is not able to give valuable hints about the props of the Header. On the other side, VSCode can recognize the props of the component perfectly.


        • Ekaterina Prigara says:

          With the provided example, I’m seeing code completion for props without any additional configuration.

          WebStorm uses Closure Compiler type syntax in JSDoc comments for describing types. For the full support for the TypeScript syntax in JSDoc comments, please follow this issue:

          If you want to use TypeScript (as VS Code does that) to check your JavaScript files, you can do that:
          – add a tsconfig.json file to your project
          – add allowJS: true to the compilerOptions section
          – once you open a .js file in the editor, you will see the results from the TypeScript language service in the TypeScript tool window as well as in the editor.

Leave a Reply to Edoardo Luppi Cancel reply

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