Base configuration

[rylnd]

I was a bit surprised to find that this configuration repo has over 150 dependencies. After looking over similar repositories (airbnb), that seems to be the norm for a full-fledged react app with a whole bunch of build tools.

However, given the flexibility of extends, I think we'd be wise to extract an "adorable-base" configuration repo that is not dependent on react or babel, and build an "adorable-react" configuration repo from that.

If anyone has interest in doing this just assign yourself to the repo; otherwise I'll probably get to it in the next week or so.

[rylnd]

One question: should this be two repos, or a monorepo? (see e.g. https://github.com/airbnb/javascript/)

[itsthatguy]

this is different from a plugin

[itsthatguy]

The long-term goal was to create a plugin that allowed for lots of different configuration options

[rylnd]

@itsthatguy okay, I'm unclear on the distinction between using a plugin and extending a configuration. I think that the airbnb approach is using "configuration objects;" what is the benefit of using a plugin over a configuration?

Can you explain what those long-term goals mean in the context of what I'm proposing?

I'm just looking to get a basic config that does not depend on babel or react stuff. If my needs conflict with your goals, I'm happy to just create a distinct eslint-config-adorable-base repo and publish that to NPM; I was only circling back here because I thought we could remove some duplication by having this repo extend from adorable-base.

[itsthatguy]

A config has only a single thing that it exports. a plugin can export multiple configs

[itsthatguy]

@rylnd the preference here is to make eslint-config-adorable a plugin, that has a base config, and a react config.

[rylnd]

@itsthatguy if it all lives in one repo and is published as a single npm package, wouldn't that mean that the superset of dependencies is required regardless of which config you're using?

Like I said, I'd been basing my architectural decisions on airbnb's repo (single repo, publishes multiple npm packages as configs, not plugins). If that's still the desire, could you point me to an example of a multi-plugin repo?

[itsthatguy]

@rylnd I say do whatever makes sense to you now. nothing is permanent.

[rylnd]

if it all lives in one repo and is published as a single npm package, wouldn't that mean that the superset of dependencies is required regardless of which config you're using?

I'm interested in the plugin approach, but I think this merits addressing: if it's true, then plugins probably isn't the way to go. All the more reason that I'm interested in an example of a multi-plugin repo.

[itsthatguy]

a node module is a node module... when you install the node module, you get all of that modules dependencies. a plugin is a node module