Ability to extend ESLint's own config

[btmills]

In other projects under the eslint org (eslint/eslint-plugin-markdown, for example), I want to adopt the same code conventions used by the core project.

For now, I manually copied the .eslintrc from this repository in eslint/eslint-plugin-markdown#8. When the eslint devDependency is upgraded, that process will need to be repeated.

Could we find a way for projects to use the same config used by eslint core?

Three possible solutions I've come up with so far:

1. Manually copy the .eslintrc from the main repository. (Disadvantage: Annoying.)
2. Include the .eslintrc in the npm distribution. (Disadvantage: Enabling or reconfiguring a rule for our own use would then be a breaking change. Could we get around that by making this a private "API" of sorts?)
3. Publish a new module, eslint-config-eslint. (Disadvantage: Adding and enabling new rules becomes even harder. Could not track eslint package's version because enabling or changing a rule would be a breaking change.)

[eslintbot]

Thanks for the issue! We get a lot of issues, so this message is automatically posted to each one to help you check that you've included all of the information we need to help you.

Reporting a bug? Please be sure to include:

1. The version of ESLint you are using (run eslint -v)
2. The source code that caused the problem
3. The configuration you're using (for the rule or your entire config file)
4. The actual ESLint output complete with line numbers

Requesting a new rule? Please be sure to include:

1. The use case for the rule - what is it trying to prevent or flag?
2. Whether the rule is trying to prevent an error or is purely stylistic
3. Why you believe this rule is generic enough to be included

Requesting a feature? Please be sure to include:

1. The problem you want to solve (don't mention the solution)
2. Your take on the correct solution to problem

Including this information in your issue helps us to triage it and get you a response as quickly as possible.

Thanks!

[nzakas]

I actually think number 3 is the only viable option. We don't need to worry about breaking changes - that's par for the course with configs. You can always choose to keep using an older version.

The larger question to me is how to manage that? I don't want an entirely new repo for our config, as that would make updating it when new rules are added a big pain.

[btmills]

If we're not concerned with breaking changes, can you explain why 2 wouldn't be viable?

Perhaps a publish script in the main repo that grabs the .eslintrc? That would probably require keeping a package.json somewhere for the config package, but that's much less inconvenient than a separate repo, which I agree wouldn't be worth it.

[nzakas]

Because 2 is an implicit contract saying that .eslintrc will always be shipped with ESLint and will be shipped in that location. 3 is an explicit contract.

Another option would be to have a predefined eslint:current configuration that you can extend (naming, as always, debatable).

[ilyavolodin]

@nzakas Could you explain a bit more why don't you want separate repository? We rarely add new rules to our own .eslintrc file (I think it's not more then once per month or even less). I don't see it as a maintenance burden.

[nzakas]

Having gone through this multiple repository thing a few times, it's something I want to avoid. We just went through the trouble of moving the tester back into this repo, and arguably that had the same update pattern as our .eslintrc.

What I want is for us to enable every rule possible so we're dogfooding, and that means turning on each new rule when PRs are sent in. Asking people to do a PR to two repositories to get that effect creates too much turbulence.

[ilyavolodin]

Ok, got it. If we want to enable every single rule that changes the equation.
What we could do in that case is keep .eslintrc in this repository, but update release job to push it to another repository and publish it to npm as eslint-config-eslint.

[nzakas]

What's the value of having a separate repo? We could just have another package.json in this one.

[ilyavolodin]

Value is that it's exposed to other people/projects And it would make it easier to use in other repositories of the organization too, since it's just shareable config

[nzakas]

You're talking about the value of publishing the config on npm. We can do that without a separate repo. I'm asking if there's any value to having a separate repo vs. keeping it in this one?

[ilyavolodin]

I wasn't aware that you can do two separate npm packages from the same repository (seems strange to me, since you have to have separate package.json for each). If that's the case, then I can't think of a reason to create separate repository.

[nzakas]

Yup, the coupling is one package.json to one npm package, repos aren't really part of the equation.

[btmills]

What are the odds we'd run into similar problems with two packages as we'd have with two repositories? That would be a point in favor of the eslint:current suggestion earlier.

[ilyavolodin]

Problem with eslint-tester was circular dependency, eslint depended on eslint-tester and eslint-tester depended on eslint. I think that will not be the case with config package. It has no reason to depend on eslint.

[nzakas]

I think the real question is whether or not there's value in having a separate npm package for our config. Doing "ESLint:current" means less for us to manage, but would we be missing any use case?

[ilyavolodin]

True. However in my mind, having "eslint:current" sort of goes against the whole "agenda free" part of the description. We are giving more weight to our own config then others by including it into distribution.

[nzakas]

We also give more weight to our own rules by including them in the distribution. "Agenda free" means we aren't forcing anyone to use something they don't want to use, it says nothing about what we decide to provide as an option.

[ilyavolodin]

It looks like we left this hanging. I, personally, lean more towards having a separate npm package but without a separate repository. Including it as eslint:current feels like forcing people to download extra files/data that they might not use in their project.

[nzakas]

I agree. Here's what I have in mind:

1. Create a packages directory
2. Create a subdirectory called eslint-config-eslint
3. Have a package.json in that directory
4. Update build script to translate .eslintrc into a JSON file and do a release whenever a regular ESLint release is done
5. Always do major releases for eslint-config-eslint, since any change is breaking

Thoughts?

[btmills]

Sounds good!

I'd amend step 4 to check to see if the config has actually changed before doing the release.

[ilyavolodin]

Sounds like a plan!

[nzakas]

Good point.

[nzakas]

Working on this.

[albertosantini]

I am sorry if I resume an old thread.

I was wondering why the latest release of eslint-config-eslint is nine months old on npm (3.0.0).

I thought step 5 above required publishing a new version, at least when a new release of eslint was released. When I use extends: "eslint", I would expect using the config version used to lint that version of eslint.

Am I missing anything?