gajus/eslint-config-canonical

Splitting into multiple packages?

tavoyne opened this issue · 6 comments

What about splitting this package into multiple packages (e.g. eslint-config-canonical-base, eslint-config-canonical-react, etc.), each one with its own dependencies?

The problem is that in most cases, only a subset of the dependencies will be used per project. Like even if I don't use Typescript in my app, now I'm downloading @typescript-eslint/parser along with this library, which is bad for memory, bad for CI, and also makes yarn complaining about unmet peer dependencies (see below).

image

gajus commented

Slitting it would defeat the purpose of keeping it a single config. The #1 complaint I hear from people migrating from Prettier to ESLint is that they need to download multiple configs, etc. They like Canonical because it is all wrapped in a single file.

One alternative that I thought of is that we could move all plugins as dependencies of eslint-plugin-canonical. Then you would not get those peer dependency warnings.

I agree that having everything in a single config makes things easier, particularly for adoption.

The alternative you suggest seems a good option to me.

But, TBH, I still prefer the idea of the package being splitted. It feels more natural. I think the slight increase in simplicity doesn't compensate for having to download a lot of dependencies which, mostly, will end up never being used.

In the end, the difference in terms of DX would be negligible.

Instead of:

yarn add --dev eslint-config-canonical

You would do, for example:

yarn add --dev eslint-config-canonical eslint-config-canonical-node eslint-config-canonical-typescript 

(Dependencies would align nicely in package.json).

And:

/* .eslintrc.js */

{
  "extends": [
    "canonical",
    "canonical-node",
    "canonical-typescript",
  ],
}

At least there should be a story how to get rid of all those warnings.

gajus commented

The whole point of canonical is to have all rules in one versioned package. Splitting them into multiple packages would defeat the purpose of a single ruleset to rule them all.

Open to documentation how to improve logs for yargs.

I use .yarnrc.yml for yarn 2+ as work around

packageExtensions:
  # Bellow dependencies of eslint-config-canonical
  eslint-config-canonical@*:
    peerDependenciesMeta:
      '@babel/plugin-syntax-flow': { optional: true }
      '@babel/plugin-transform-react-jsx': { optional: true }
      graphql: { optional: true }
      typescript: { optional: true }
      vitest: { optional: true }
  eslint-plugin-canonical@*:
    peerDependenciesMeta:
      eslint: { optional: true }
      typescript: { optional: true }
      eslint-plugin-import: { optional: true }
  '@graphql-tools/graphql-tag-pluck@*':
    peerDependenciesMeta:
      '@babel/core': { optional: true }