Webstorm logo

The WebStorm Blog

The Smartest JavaScript IDE

Early Access Program

WebStorm 12 EAP, 144.3600: bug fixes and improvements

Welcome a new WebStorm 12 EAP build (144.3600)!

You can download it here or, if you have a previous EAP build (144.3357) installed, you should soon get a notification in the IDE about a patch update.

The highlights of this update include:

  • Support for Git worktrees: you can work with them just like you do with the regular repositories.
  • The updated look and feel of the Git Log: now it has a better-looking toolbar and thinner splitters, the table headers have been removed.
  • Missing import statement inspection now works for the client-side JavaScript.
  • WebStorm bundled TypeScript compiler was updated to version 1.8-beta

The full list of issues addressed in this EAP build is available in the Release notes.

Read about the features and improvements added in previous WebStorm 12 EAP builds:

  • WebStorm 12 EAP, 144.3357: SSH Console, Extract field refactoring in TypeScript, support for debugging Node.js apps built with Webpack, and more.
  • WebStorm 12 EAP, 144.3143: Unused imports warning, code assistance intsconfig.json.babelrc and .eslintrc, remote run and debug for Node.js apps, Vagrant integration, debugging Electron apps, and further improvement in Angular 2 support.
  • WebStorm 12 EAP, 144.2925: Inline rename, smarter auto-imports and Optimize imports action for TypeScript, debugging async client-side code, and improvements in Angular 2 support.

Please report your feedback to our issue tracker. To get notifications of new EAP builds as they become available, subscribe to the EAP channel in Preferences | Appearance & Behavior | System Settings | Updates

– JetBrains WebStorm Team

Comments below can no longer be edited.

2 Responses to WebStorm 12 EAP, 144.3600: bug fixes and improvements

  1. Michael Hasenstein says:

    February 5, 2016

    I would like to have bug #WEB-17446 (https://youtrack.jetbrains.com/issue/WEB-17446) reopened, explanation see there.

    Two general questions:

    1) In a case like that – it’s the same problem but not _exactly_ the same – is it better to open a new ticket or amend the existing one?

    2) If I amend a closed ticket like I did in this case, is this sufficient for the ticket to regain attention? I fear even if notifications are sent when I add the new comment unless the assigned code reacts immediately it may be forgotten, since the ticket state is “closed/fixed”. So it comes back to my first question too.


    • Ekaterina Prigara says:

      February 5, 2016

      We have reopened the issue and will have a closer look.
      Thanks for your comment, really appreciate that.
      If it’s the same problem or very similar one, it’s better to comment on the existing issue rather than create a new one. That’s good for keeping the context of the problem and the fix.
      We all get email notifications about the comments and new issue, so either a QA engineer or a developer will see the comment and reopen the ticket.