Prettier-eslint: Remove rules that aren't fixable

Created on 17 Jan 2017  路  10Comments  路  Source: prettier/prettier-eslint

Each rule you add to the ESLint config adds overhead. If it's not fixable then it's not useful overhead. We should improve perf by removing any rules from the config that aren't fixable. I'm not sure whether it's possible to know, but if it is, we should try. Could really speed things up I think.

enhancement

Most helpful comment

In JS rules file:

module.exports = {
    meta: {
        docs: {
            description: "require or disallow semicolons instead of ASI",
            category: "Stylistic Issues",
            recommended: false
        },

        fixable: "code",
...

but parse everytime repo.... and how deal with plugin?
I will begin the development vs code extension of a weekend and think about it

All 10 comments

ping @gyandeeps, I think you could shed some light here :)

Well this could get tricky because if the user sets the useEslintrc option then you have to do a lot of work (which i think is not worth it).
So I would say visit this when we actually see an issue.

What we do with new rules or rules that will fixable in the future?

Yeah, we'd probably want a way to dynamically identify rules that are fixable. If there's a way to do that. Somehow the eslint website knows, but I'm not sure whether that's manually maintained or not.

In JS rules file:

module.exports = {
    meta: {
        docs: {
            description: "require or disallow semicolons instead of ASI",
            category: "Stylistic Issues",
            recommended: false
        },

        fixable: "code",
...

but parse everytime repo.... and how deal with plugin?
I will begin the development vs code extension of a weekend and think about it

Now that the atom plugin and the CLI are working well, I've applied them to all three prettier-eslint related projects and I've gotta say that it could be handy to have things be a tad bit faster. On files over 100 lines, perf issues are slight, but noticeable. Anyone willing to throw their hat into making prettier-eslint faster, please be my guest!

Is there any rationale behind making prettier-eslint always do eslint --fix ? https://github.com/prettier/prettier-eslint/blob/cc5f683e7a1a1e5aefce101b97a5e6430716843f/src/utils.js#L99

Is it a good idea to make fix optional ?

If it's something we would like to do, i can submit a PR.

The whole purpose of the tool is to automatically format your files. Running through prettier first and then eslint with --fix.

If you only want lint errors printed then using eslint with eslint-plugin-prettier will give you linting errors based on prettier too.

@zimme - sorry for not being very clear. I lost my point after rephrasing a previous question :-)

I was thinking about providing an option to pick the rules which can be autofixed (even if it can be autofixed by eslint). Basically, having an option to get errors on some and autofix some.

Not sure if eslint already supports something similar ?

I think this would be covered by: https://github.com/prettier/prettier-eslint/issues/118

Want to move discussion to that?

Was this page helpful?
0 / 5 - 0 ratings