Early Access Program

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

Comments below can no longer be edited.

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

  1. Avatar

    Vadym Milichev says:

    February 12, 2019

    The following Confluence page is outdated

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

    • Ekaterina Prigara

      Ekaterina Prigara says:

      February 13, 2019

      Thanks, I’ve added a link to the website there.

  2. Avatar

    Martijn says:

    February 12, 2019

    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.

    • Avatar

      Maxim Kropotov says:

      February 13, 2019

      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. Avatar

    Gabriel Perry says:

    February 20, 2019

    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.


  4. Avatar

    Bhish says:

    May 26, 2019

    The monorepo support for ESLint is not working for me.

    We have a lerna repo with three typescript packages contained inside: shared, vessel, website.

    Shared is a library of react components imported by other packages.
    Vessel and Website are CRA-generated projects.

    I have eslint setting set to Auto in Webstorm.

    Shared package works as expected and linting rules are applied. This is using ESLint with @typescript-eslint/parser.

    For Vessel it complains with: “Parsing error: File /tsconfig.json not found”. Notice how it looks for tsconfig.json in the root, rather than in /packages/vessel. This suggests that it is not running eslint from the vessel package but instead the top-level? I have to be honest here in the fact that we have overridden CRA lint settings in this package with our own eslintrc and installing eslint packages and plugins ourselves.

    For Website it complains with: “Error: Cannot find module ‘eslint-config-react-app'”. There is no special configuration in the project, just the CRA standard setup. Our lerna project is setup with react-scripts set as *no-hoist*, therefore CRA should be functioning in the normal. This means that website deps look like this:


    It seems that WebStorm is not able to understand that it can find the eslint config package with the react-scripts managed dependencies?

    Until this feature works smoothly I have to force the IDE into looking at the shared package lint rules and applying them across the entire monorepo…

    Thanks in advance for your help.

    • Avatar

      Maxim Kropotov says:

      May 28, 2019

      Bhish, You’re right, it seems that the wrong working directory is used in this case, this is a bug that should be fixed. Configuring @typescript-eslint for a package inside a monorepo should definitely be supported.

      I’m not sure I understand your project structure exactly, but I was able to reproduce a similar issue using yarn workspaces instead of lerna: https://youtrack.jetbrains.com/issue/WEB-39118

      Please follow that issue to see if helps with your project as well. We’ll try to resolve it soon.

  5. Avatar

    Aaron Harun says:

    August 13, 2019

    Eslint 6 fails to load plugins if the package.json file is not at the root of the repo:

    |__ build
    |__ package.json
    |__ .eslint
    |__ node_modules
    |__ src
    |__ something
    |__ someFile.js
    |__ .eslint ({“extends”: [“./build/.eslintrc”]})

    The root eslint points to the main eslint file inside the build directory.

    All commands are usually run inside the build directory, “automatic” configuration results in no eslint errors being shown, but manual configuration to /build/node_modules/eslint results in plugins not being found.

    Running global eslint in the root folder has the same error about the plugin not being found, so it seems webstorm is not respecting the binary location relative to the eslint package.

    This configuration worked in 2019.1 and all that was needed was pointing to the correct node_modules folder.

    • Ekaterina Prigara

      Ekaterina Prigara says:

      August 14, 2019

      Hi Aaron,
      Sorry for the delayed reply.
      Can you please file a new issue on our issue tracker and, if possible, attach a sample project? The problem is that we are not sure we were able to correctly reproduce your project structure: Is that right that all files and folders you’ve listed are inside the resources folder? Or package.json, node_modules and one of the .eslint files are located in the build folder? Thank you!