Prettier-eslint: Don't instantiate eslint for each linted file

Created on 14 Mar 2017 · 10Comments · Source: prettier/prettier-eslint

Currently prettier-eslint instantiates eslint for each linted file. The results seems to be that for every file eslint config is reading its configuration, probably hitting the performance.

It would be nice if someone did research if it's possible to make eslint read configuration just one time (unfortunately I don't have time to do so).

It seems to be the case based on output of prettier-eslint in #53

enhancement help wanted no-issue-activity

Source

sheerun

Most helpful comment

I'm thinking we should just be able to read the eslint config from prettier-eslint-cli and forward that to prettier-eslint to make sure this package doesn't try and read the options from the config file.

So this wasn't as easy as I thought as eslint seem to only have an api to get the config for a file, and we're accepting globs in prettier-eslint-cli. Memoizing seems like the most viable option.

zimme on 12 Oct 2017

👍2

All 10 comments

We could probably memoize the function (using fast-memoize) or lodash.memoize) on a per-directory basis. That could speed things up significantly...

kentcdodds on 17 Apr 2017

I'm thinking we should just be able to read the eslint config from prettier-eslint-cli and forward that to prettier-eslint to make sure this package doesn't try and read the options from the config file. Thoughts?

For editors using this package, they should also be able to read settings from config file if present and forward that to this package to make sure this package doesn't try and read from the config file.

zimme on 12 Oct 2017

Sounds fine

kentcdodds on 12 Oct 2017

👍1

I'm thinking we should just be able to read the eslint config from prettier-eslint-cli and forward that to prettier-eslint to make sure this package doesn't try and read the options from the config file.

So this wasn't as easy as I thought as eslint seem to only have an api to get the config for a file, and we're accepting globs in prettier-eslint-cli. Memoizing seems like the most viable option.

zimme on 12 Oct 2017

👍2

I'm looking into a different way of doing config resolving and merging which will involve the consumers of our api a bit more in the config decision process.

With this, I'm hoping that I can just use the given configs and only try and resolve configs when configs aren't provided in the api calls.

zimme on 21 Dec 2017

FYI, here's some stats from a project I'm running:

Rule                         | Time (ms) | Relative
:----------------------------|----------:|--------:
prettier/prettier            | 12538.062 |    59.6%
import/no-duplicates         |  3026.915 |    14.4%
no-unused-vars               |  1163.364 |     5.5%
react/prop-types             |   601.383 |     2.9%
react/no-unused-prop-types   |   452.671 |     2.2%
no-unmodified-loop-condition |   313.946 |     1.5%
camelcase                    |   258.667 |     1.2%
no-useless-return            |   165.710 |     0.8%
no-regex-spaces              |   159.656 |     0.8%
no-implied-eval              |   145.517 |     0.7%

Any improvement to prettier would give substantial gains. LMK how can I help.

joaomilho on 28 Dec 2017

I recently added functionality to filter out all rules that aren't marked as fixable before I hand eslint the rules. We should probably filter out prettier/prettier here too, as we have already run prettier before eslint, or will run prettier after eslint depending on prettierLast.