Work together on eslint-config-defaults

[baer]

Hello! I wanted to propose a collaboration between this repo and https://github.com/walmartlabs/eslint-config-defaults.

I originally set out to build config-defaults because I was tired of copy pasting my eslint config around and trying to keep them up to date across lots of projects. Eslint's extends key fixes the distribution problem but there are still two issues:

1. Managing the eslint config file is a pain in the ass even though it is centralized. New rules are added, removed, moved and deprecated all the time and organization is terrible.
2. Just getting up and running for a new project is not straightforward anymore and I strongly believe that code quality tooling should be well suited to those who are just starting out as they're often the ones who need it most after all.

So with this project I centralized a few configs from major players, I committed to staying on top of the latest rules (and deprecations) and most importantly I made the config composable which allows them to be easily mixed and matched!

---

It's obvious that you all saw the same problems and it has been enormously helpful to a lot of people but I want to take your config one step further and I am asking for your help. With eslint-config-defaults I want to try to centralize the config from a few thought leaders around the web so that folks have fast, standard and up to date options from the start.

I've been maintaining a few "unofficial" configs for a while now but it's duplicate effort and my hope is to try to collaborate/consolidate. For my part, I am committed to staying on top of the latest rules as they change. I should mention that you all have quite a few missing rules already :).

Potential Objections(?):

• We need quick access to the repo to make changes. - I'm happy to try to get your maintainers added to the project.
• The project is under walmartlabs and I'm not too sure I like that. - It's possible we could spin this out into it's own org. No promises, I'd have to talk to legal and such about what we can do but we may be able to find a way.
• This project is an important part of our OSS portfolio that we're not going to shut down. - You could easily take config-defaults as a dependency and keep this exactly how it is.

Anyway, I wanted to start a conversation and see if we can make it work for both of us.

@rmg @sam-github

[superkhau]

@rmg @sam-github Related to https://github.com/strongloop/loopback/issues/1749. I would like to hear your opinions on this too.

[rmg]

We're in a different scenario than @sindresorhus described in https://github.com/google/eslint-config-google/issues/4#issuecomment-167099822 in that this repo isn't really actively maintained so much as "mostly done".

I'm not sure how to do that without having more access/control over the eslint-config-defaults repo than I think is appropriate. Your apparent willingness to rev the major version as often as necessary makes me hopeful you understand the significance of this.

Currently, our repos that make use of this config run eslint as a pretest script, which effectively causes linting errors to fail the build. This is typical. What isn't typical is how we have our CI configured to build downstream repos against PRs. Every time we tweak the config here in a PR, that PR is tested against every one of our modules that uses it and we can tell right away if we are about to introduce an unintentionally breaking change.

@baer what are your thoughts on how to detect and handle breaking changes?

@sam-github what do you think? I think having one less repo/module to maintain would be a boon (albeit small, given how slow moving this repo is).

Overall I think I'm +0 on this. I don't know that we have the resources right now to do the migration/integration, but if someone else did it and it "just worked" then I wouldn't object. Once it was in a release of eslint-config-defaults our projects would have to be moved over one at a time and that's when we would see how successful it was.

[rmg]

@superkhau as an experiment, this repo could add eslint-config-defaults as a dependency and be restructured to use the decomposed rules and the general repo layout of eslint-config-default to see if it works for us. A PR doing that would give us a good idea of the impact on our modules.

[superkhau]

I will submit a PR as part of my spike at https://github.com/strongloop/loopback/issues/1749.

TBH, I am also +0 on this ATM. Seems like a lot of hoops to jump through for configs that are specfic to our org. I don't see the huge benefit to decentralizating our configs. The rule composition is a nice feature though.

[baer]

Thanks @rmg and @superkhau for taking a look at this. That's a novel but neat CI setup you have. I do understand that there are more hoops to jump through to make this work and if it's looking like a NoGo for you that is completely fine. I just thought I'd ask. My main goal is not providing immediate value to strongloop though I think that there is some. My goal is to provide benefit to the open source community with a small handful of easy to use / customize configs so we don't find npm littered with the detrius of our project management woes. If you don't have the resources to make that transition (or don't see the value) I would fully understand that. I'm very grateful for all the awesome stuff you folks do.

As for the decomposition, I'm happy to put in the work to make that happen if it would be useful for you. In fact if it would be okay I may maintain an unofficial version over in the defaults repo. Thoughts?

Finally, for detecting and handling breaking changes - I try to follow semver as best I can but since this is not a library with an API to speak of here is how I try to break it down:

major - The addition of any new rule set to the "on" state OR the reorganization of the repo. Basically, anything that would break somebody's CI. minor - The addition of new rules in the "off" state. This is generally a ESLint upgrade patch - Updates to the README, corrections to syntax, linting and other assorted non-breaking things.

It's worth mentioning that a major rev could happen for a change in another set of config. I'm not sure yet how to handle that and am very much open to suggestions.

[sam-github]

I don't see any advantage to us. We don't need to compose other people's personal style prefs with ours. This entire repo is basically 100 lines of json that we rarely change, and if we DO want to change it, I don't see why we should depend on an external repo, or have to change major versions in our deps if the upstream walmart repo bumps its major because of a config we don't use... one of the problems with dumping multiple organization's json configs into a single repo is you are forced to bump majors when completely unrelated orgs change their personal styles. Doesn't seem helpful to me!

I also don't see any advantage to other people: why should they use our personal style? You could copy this file out into your walmartlabs repo as a snapshot of what we do at this moment, freeze it, and maybe people would find that useful, or maybe not, but then at least we could be free to change this as we wish (our CI will tell us if we broke any of our repos).

[baer]

Sounds good, feel free to close this issue. Have a great new year :tada:!

[sam-github]

You, too, @baer, may the sun shine on your keyboard! Or whatever we say to wish people good coding. :-)