Eslint-config-coralloy NPM

eslint-config-coralloy

Installation

$ pnpm add -D eslint-config-coralloy

// eslint.config.js

import configCoralloy from "eslint-config-coralloy";
import { createTypeScriptImportResolver } from "eslint-import-resolver-typescript";
import tseslint from "typescript-eslint";
import { version as vueVersion } from "vue";

export default tseslint.config(
  ...configCoralloy.configs.base(
    // Pass any additional configs here, the function handles the internal order

    // If using Vue, add the following config:
    ...configCoralloy.configs.vue,
    ...configCoralloy.configs.vueI18n, // if using vue-i18n
  ),

  {
    settings: {
      "import-x/resolver-next": [
        createTypeScriptImportResolver({
          project: ["./tsconfig.json"],
          // or, if using a single eslint config for multiple projects in a monorepo:
          // project: ["./tsconfig.json", "./packages/*/tsconfig.json"],
        }),
      ],
    },
  },

  // If using Vue, you can also enable the following rule:
  {
    rules: {
      "vue/no-unsupported-features": ["error", { version: vueVersion }],
    },
  },
);

Import Patterns

We provide some patterns that you can import and use to configure the no-restricted-imports rule.

Example usage:

// eslint.config.js
import configCoralloy from "eslint-config-coralloy";

module.exports = {
  // ...

  rules: {
    "no-restricted-imports": [
      "error",
      {
        patterns: [
          configCoralloy.importPatterns.noDeepRelative,
          configCoralloy.importPatterns.noLodash,
        ],
      },
    ],
  },
};

For the whole list of patterns and their descriptions, use IntelliSense capabilities of your editor or check the source code.

Migration from 0.5.x to 0.6.x

eslint-config-coralloy now only supports ESLint v9. See the ESLint v9 migration guide for more information.

The Vue configuration is no longer part of the "default" configuration. It can be added to your project separately when needed, easily. See the example below for more information.

The eslint config now have the following rules enabled by default, so you can remove them from your configuration if you have them:

"object-shorthand": ["error", "always"],
"no-debugger": process.env.NODE_ENV === "production" ? "error" : "off",
"no-console": [
  process.env.NODE_ENV === "production" ? "error" : "warn",
  { allow: ["error"] },
],
```

Here is an example of how to update your ESLint configuration:

Before:

```js
// .eslintrc.js or .eslintrc.cjs
const { noDeepRelative, noLodash } = require("eslint-config-coralloy/patterns");

module.exports = {
  extends: ["coralloy", "coralloy/vue-i18n"],
  rules: {
    "vue/no-unsupported-features": [
      "error",
      { version: require("vue").version },
    ],

    "no-restricted-imports": [
      "error",
      {
        patterns: [noDeepRelative, noLodash],
      },
    ],
  },
};

After:

// eslint.config.js
import configCoralloy from "eslint-config-coralloy";
import tseslint from "typescript-eslint";
import { version as vueVersion } from "vue";

export default tseslint.config(
  ...configCoralloy.configs.base(
    ...configCoralloy.configs.vue,
    ...configCoralloy.configs.vueI18n,
  ),

  {
    rules: {
      "vue/no-unsupported-features": ["error", { version: vueVersion }],

      "no-restricted-imports": [
        "error",
        {
          patterns: [
            configCoralloy.importPatterns.noDeepRelative,
            configCoralloy.importPatterns.noLodash,
          ],
        },
      ],
    },
  },
);

Migration from 0.4.x to 0.5.x

source.organizeImports was problematic in behavior and performance. We already have sorting/grouping through import-x plugin, so we only needed to be able to remove unused imports. To do so, we have added eslint-plugin-unused-imports as part of coralloy/import config. You can now remove source.organizeImports from .vscode/settings.json:

"editor.codeActionsOnSave": [
-  "source.organizeImports",
  "source.fixAll.eslint",
  "source.fixAll.stylelint"
],

The use of relative imports is now limited to one level at most, e.g. ./* and ../*, not ../../*. This is to enforce a more structured project and improve readability. If you need to import from a deeper level, consider using an alias. The new rules can't be fixed automatically, so you will need to make the necessary adjustments manually, if you have such imports. Example:

// inside src/components/something/foo-bar.vue
// need to import src/components/baz.vue
- import Baz from "../../baz.vue";
+ import Baz from "src/components/baz.vue";

// inside src/modules/some-module/sub-module/index.ts
// need to import src/modules/another-module/another.service.ts
- import AnotherService from "../../another-module/another.service";
+ import AnotherService from "src/modules/another-module/another.service";

To disable this specific pattern, or better yet, to add more patterns, see the Import Patterns section.

Migration from 0.3.x to 0.4.x

typescript-eslint has been updated to v8, so check typescript-eslint v8 announcement for more info.

We have switched from eslint-plugin-import to eslint-plugin-import-x. So, change import to import-x in your .eslintrc.js file and any ESLint disable comments. Example:

// .eslintrc.cjs
rules: {
-  "import/no-unresolved": "error",
+  "import-x/no-unresolved": "error",
}

- // eslint-disable-next-line import/no-unresolved
+ // eslint-disable-next-line import-x/no-unresolved

Migration from 0.2.x to 0.3.x

typescript-eslint has been updated to v7, so check typescript-eslint v7 announcement for more info.

Migration from 0.1.x to 0.2.x

You can now remove

{
  parserOptions: {
    // https://github.com/typescript-eslint/typescript-eslint/tree/main/packages/parser#parseroptionstsconfigrootdir
    tsconfigRootDir: __dirname,
  },
}

as we now use project: true (https://typescript-eslint.io/packages/parser/#project) to autodetect the correct tsconfig file. tsconfigRootDir won't have any effect under the new setup, so removing it is just for the sake of clean code.

Dev notes

parserOptions.project will search for a tsconfig into the same folder as the eslint config file, since we suppose linting will be managed at root level and only one tsconfig will be present. It can be overridden in userland if needed to point to a different tsconfig.

We decided to go for eslint-config-coralloy instead of @coralloy/eslint-config due to consistency of the name to use when exporting multiple configs. Using eslint-config-coralloy the base can be included using coralloy and additional ones with coralloy/something. Using scoped modules would force to use the expanded form of @coralloy/eslint-config/something when using a config different than the default one, but only @coralloy for basic config.