eslint-config-canonical icon indicating copy to clipboard operation
eslint-config-canonical copied to clipboard

Splitting into multiple packages?

Open tavoyne opened this issue 3 years ago • 3 comments
trafficstars

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

tavoyne avatar Dec 21 '21 08:12 tavoyne

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.

gajus avatar Dec 21 '21 13:12 gajus

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.

tavoyne avatar Dec 21 '21 15:12 tavoyne

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",
  ],
}

tavoyne avatar Dec 21 '21 15:12 tavoyne

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

tbsvttr avatar Oct 28 '22 07:10 tbsvttr

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.

gajus avatar Jan 16 '23 18:01 gajus

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 }

sotnikov-link avatar Sep 28 '23 14:09 sotnikov-link