WebStorm 2019.1 EAP #3: improved support for ESLint and TSLint

WebStorm 2019.1 Early Preview build #3 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.

Toolbox App is the easiest way to get EAP builds. 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.1 EAP

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

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

Improved Support for ESLint and TSLint

We have completely redesigned our integration with ESLint and TSLint to improve the way it works in monorepos (including projects managed by lerna and yarn workspaces) and projects with multiple linter configurations.

Before, WebStorm could run only one linter’s service per project. So if you had different linter versions with different configs in different parts of your project, still only one ESLint or TSLint process would run, resulting in some configs being ignored or some plugins working incorrectly.

Now, the IDE will start a separate process for every package.json that lists a linter (ESLint or TSLint) as a dependency, and it will process everything below it as if it were invoked with .bin/eslint **/*.js (in case of ESLint).

This behavior is on by default for all new projects.

To switch to the new mode in the existing projects, go to Preferences/Settings | Languages and Frameworks | JavaScript | Code Quality Tools | ESLint or TypeScript | TSLint and select Automatic ESLint/TSLint configuration.

If you need to run a globally installed linter, pass additional options to it, or add a custom rules directory, you configure all these additional options if you select Manual configuration.

Highlighting for failed line in test

If you’ve run tests in WebStorm and some of them have failed, now you can see where the problem has occurred – right in the editor. The IDE will use the information from the stack trace and highlight the failed code. On hover, you’ll see the error message from the test runner. And you can immediately start debugging the test.

Highlighting for the failed line in test

This works with Jest, Karma, Mocha, and Protractor.

Camel case support for CSS Modules

If you’re using CSS Modules in your project, code completion for classes in the JavaScript file will now suggest camel-cased versions of class names with dashes:

CSS Modules: completion for class names with dashes

Support for Less 3.0 features

In Less files, we’ve added support for the Less 3.0 feature, properties as variables.
After typing $ as a value, you will now see suggestions for the property names used in this scope that can be used as variables:

Less 3: properties as variables

WebStorm now also supports the if syntax in Less.

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.

5 Responses to WebStorm 2019.1 EAP #3: improved support for ESLint and TSLint

  1. Vadym Milichev says:

    The following Confluence page is outdated
    https://confluence.jetbrains.com/display/WI/WebStorm+EAP

    Please add an alert comment there with the link to the blog.

  2. Martijn says:

    Within our mono repo, we have a tslint.json file in some packages and an .eslintrc file in some others. We do not use linter values in the package.json. Do we have to add these to make this work? I still get eslint validation messages in my TypeScript packages.

    • Maxim Kropotov says:

      Martijn, Hi!
      > We do not use linter values in the package.json
      It shouldn’t matter if the linter configuration is defined in a package.json section or a separate configuration file

      Is it possible that your TypeScript files are located under an .eslintrc file that contains babel-eslint as ‘parser’?
      Processing TypeScript files with ESLint is a babel-eslint 7.0 feature (https://github.com/babel/babel-eslint/issues/505) and is supported by the IDE since 2018.3 (https://youtrack.jetbrains.com/issue/WEB-29829).
      In this case, adding *.ts to an .eslintignore should fix the issue.

      If that didn’t help, could you please open an issue in https://youtrack.jetbrains.com/issues?q=%23WEB?
      It would help if the issue contained the relevant parts of your project structure: the .eslintrc and tslint.json files, package.json files and where they’re located in your project.

  3. My 2 cents:

    I’ve noticed that using PhpStorm to write Angular code (on a Macbook Pro), the linter running inside PhpStrom causes my CPU fan to run constantly. Other devs on my team (running Linux) have noticed the same thing. Even if one makes a small change to a single file, it seems the linter runs for the whole Angular project. (We use Angular on the frontend and PHP on the backend.)

    I’m hoping this update will make the linter only lint the single file that’s changed, not the whole project as that seems completely wasteful and a waste of CPU cycles.

    Thanks.

Leave a Reply

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