Feature request: rulesdir option in .eslintrc

I’m using sublime-eslint as well as the CLI itself where I use --rulesdir. sublime-eslint does allow CLI switches, but only on a global basis, not per-project (which I think is more of an SublimeLinter issue). This presents the problem that sublime-eslint would fail on line 1 of every file because of the custom rule being present in .eslintrc.

Ideally, I think every CLI options should have a counterpart in .eslintrc to enable full portability, with CLI options taking precedence if both are present.

Another alternative I could see is to not hard-fail when a custom rule isn’t found, and continue with the other rules present, but it surely isn’t optimal.

[platinumazure]

@zertosh Assuming you know which proposal we want to focus on, you may certainly create the issue. (I haven’t been following closely and am also not TSC, but I can at least assure you that the TSC does not need to drive the new issue creation.)

[zertosh]

I would like to revive this issue in light of “Breaking: New Linter API” https://github.com/eslint/eslint/pull/8465 and the current state of loading plugins by path (https://github.com/eslint/eslint/issues/3458).

--rulesdir is a great approach for project specific rules. It’s used by ESLint (link), Node (link), and extensively at Facebook. Unfortunately, --rulesdir is only available as a flag, and not something that can be specified in an .eslintrc. This means that running a plain eslint command doesn’t fully work. So IDEs and tooling don’t work without additional per-project configuration on the part of the user.

The way we’ve dealt with this at Facebook is by using a js configuration that uses private APIs to simulate what --rulesdir does:

// .eslintrc.js
const Rules = require('eslint/lib/rules');
Rules.load(path.join(__dirname, 'resources/eslint-rules'));

In ESLint v4, this won’t work anymore due to https://github.com/eslint/eslint/pull/8465.

The proposed alternative to --rulesdir is plugins. But that has its own set of (harder) problems. For one, they must be in node_modules - npm link and file:// create other problems, if anyone is interested, I’ll delve into them. The idea of loading plugins by path would solve the --rulesdir use case, but that discussion is stalled. I don’t think that problem is solvable given the requirement that it addresses name collisions.

This discussion was ended with:

The discussion is done. There are a lot of problems with --rulesdir, not the least of which being naming collisions between custom and native rules.

I would argue that those problems are no different from say having a typo in your eslintrc. It’s part of your own custom setup, so it’s on you to fix it. I’d even go as far as to say that being able to override a native rule is a feature, and not a bug.

I’m really concerned about what I’m going to do roll out ESLint v4 internally at Facebook, if we can’t make plain eslint commands just work on projects with custom rules. I’d really like a rulesDir config that has the same status as root (only available in local configs). If this is something that would be acceptable, I can submit PR.