@krakentech/eslint-config
Advanced tools
A globally shareable ESLint config for Octopus Energy repositories.
A publicly available ESLint config by Octopus Energy Group.
This package provides a wide range of "recommended" ESLint configs with the goal of minimising end-user configuration and increasing consistency across projects. It is designed around ESLint v9 to allow for easily shareable, modular and extensible configurations by leveraging the new "Flat" config files.
We publish our ESLint config publicy on npm. No registry token or
authentication is required to install the config. Install it alongside the latest eslint version using your preferred
package manager:
pnpm add -D @krakentech/eslint-config eslint
yarn add -D @krakentech/eslint-config eslint
npm install --save-dev @krakentech/eslint-config eslint
[!NOTE] If you are using a monorepo it's still recommended to install the package at the root of the project. ESlint v9 is now able to apply rules top down, making it trivial to limit specific rule-sets to the right files. For example, the recommended NextJS package can easily be restricted to
apps/webif that is the only NextJS application in the monorepo.
ESLint v9 now enforces the use of a file named eslint.config.js. This should be placed at the root of your project. Configuration of the whole repository can be done from this single file. Simply load the package and export linters.load(FlatConfig, ...).
Each FlatConfig only requires the user to define which files should have which plugins applied to them (or ignores) and which plugins the config extends from. You can pass as many configs as you like.
[!IMPORTANT] If you don't define any
filesfor a config, the default behaviour it to lint all project files! This may affect performance.
| Single Package Example | Monorepo Example |
|---|---|
|
|
[!TIP] We support both CJS and ESM config files! You can use
importandexport defaultif your package package type is set tomodule.
Whilst we suggest that you try to use the recommended configurations where possible to maintain consistency across projects, it is still simple to "extend" our recommended configs and "override" specific rules.
For example, lets say we want to create a ReactJS project that uses Typescript and disables the @typescript-eslint/no-explicit-any rule:
// eslint.config.js
const linters = require("@krakentech/eslint-config");
module.exports = linters.load(
// ... other configs
{
files: ["**/*.{ts,tsx}"],
extends: [
// Load recommended Javascript rules
...linters.configs.javascript.recommended,
// Load the recommended typescript configs
...linters.configs.typescript.recommended,
// Then extend it with the React config
...linters.configs.react.recommended,
],
// Override a specific rule
rules: {
"@typescript-eslint/no-explicit-any": "off",
},
},
);
// eslint.config.js
const linters = require("@krakentech/eslint-config");
module.exports = linters.load(
// Global ignores across the whole repo
{
ignores: ["**/node_modules/**", "**/build/**", "**/*.typegen.*/**"],
},
// Apply Javascript recommended rules to all js(x) and ts(x) files
{
files: ["**/*.{js,jsx,ts,tsx}"],
extends: linters.configs.javascript.recommended,
},
// Apply next recommended rules to all apps
{
files: ["apps/**/*.{ts,tsx}"],
extends: linters.configs.next.recommended,
},
// Only apply typescript rules to packages
{
files: ["packages/**/*.{ts,mts,cts}"],
extends: linters.configs.typescript.recommended,
},
// Applies react rules to all react files. This should also catch most test
// files too.
{
files: ["**/*.{jsx,tsx}"],
extends: [
...linters.configs.react.recommended, // Includes jsxa11y
],
},
// Applies jest rules to test files
{
files: ["**/*.spec.{js,jsx,ts,tsx}"],
extends: linters.configs.jest.recommended,
},
);
[!TIP] Some plugins have "utility" configs that do something specific to that plugin (usually to disable rules). Use these the same way you would use the
baseconfigs.
extendsload utility automatically merges configs inside of the extends field into a single config. This means we don't have to do fiddly spreading of multiple base configs.
export type LinterConfig = {
base: FlatConfig;
recommended: ConfigArray;
utils?: Record<string, FlatConfig>;
};
export type PackageConfig = {
load: (...configs: InfiniteDepthConfigWithExtends[]) => ConfigArray;
configs: Record<string, LinterConfig>;
};
The following plugins are supported by this package. Many of the recommended ConfigArray's only contain the base plugin, however, the recommended Typescript, React and NextJS configs contain multiple plugins, for which the table below also indicates the other plugins that are loaded.
| Plugin | Typescript | React | NextJS |
|---|---|---|---|
@eslint/js | ✅ | ⛔ | ✅ |
typescript-eslint | ✅ | ⛔ | ✅ |
eslint-plugin-import | ✅ | ⛔ | ✅ |
eslint-plugin-simple-import-sort | ✅ | ⛔ | ✅ |
eslint-plugin-react | ⛔ | ✅ | ✅ |
eslint-plugin-react-hooks | ⛔ | ✅ | ✅ |
eslint-plugin-jsx-a11y | ⛔ | ✅ | ✅ |
@next/eslint-plugin-next | ⛔ | ⛔ | ✅ |
eslint-plugin-turbo | ⛔ | ⛔ | ⛔ |
@vitest/eslint-plugin | ⛔ | ⛔ | ⛔ |
eslint-plugin-jest | ⛔ | ⛔ | ⛔ |
eslint-plugin-prettier | ⛔ | ⛔ | ⛔ |
[!IMPORTANT] The recommended configs are configurations we think you should use in your projects, not that they necessarily use the recommended rules sets. Whilst most do use the recommended rule sets, it's good to check which rules sets using the JSDoc strings on each export or the plugin details below.
@eslint/jsno-console - ["error", { allow: ["warn"] }]typescript-eslintWe use the "Strict TypeChecked" rules (which automatically brings in the "Recommended" rules) to provide the most accurate type checking.
@typescript-eslint/no-unused-vars
_ prefix for unused variables{ ignoreMe, ...butNotMe } = someObject@typescript-eslint/consistent-type-importstype keywordimport { type Foo } over import { Foo }import/consistent-type-specifier-style to ensure import consistency.The following have been disabled:
@typescript-eslint/no-confusing-void-expression - Off@typescript-eslint/restrict-template-expressions - Off@typescript-eslint/no-unsafe-enum-comparison - Off@typescript-eslint/unbound-method - Off@typescript-eslint/no-floating-promises - Off[!TIP] We provide the
configs.typescript.utils.disableTypeCheckingutility to disable the type checking rules if you need to disable type checking for whatever reason (e.g. old JSX only components).
eslint-plugin-import and eslint-plugin-simple-import-sortWe use both packages in configs.imports.recommended. We prefer eslint-plugin-simple-import-sort for import sorting because it requires less configuration to apply sensible sorting, is easier to configure and only creates an single issue if there's an error in the sorting. We also include eslint-plugin-import for a few rules that the former does not handle:
import/first - Ensure all imports appear before other statements.import/newline-after-import - Enforce a newline after import statements.import/no-duplicates - Forbid repeated import of the same module in multiple places.import/consistent-type-specifier-style - Ensure that we consistently use import { type Foo }.configs.imports.utils.disableSimpleImportSortWe provide the ability to disable the simple-import-sort plugin if it does not fit well with your project. Simply extend your config with this utility like so:
// eslint.config.js
import linters from "@krakentech/eslint-config";
export default linters.load({
files: ["**/*.{ts,tsx}"],
extends: [
...linters.configs.typescript.recommended,
linters.configs.imports.utils.disableSimpleImportSort,
],
});
eslint-plugin-react, eslint-plugin-react-hooks and eslint-plugin-jsx-a11yeslint-plugin-jsx-a11y Strict Rule Set
react-hooks/rules-of-hooks - Enforce rules of hooks.react-hooks/exhaustive-deps - Validate hook dependency arrays.react/prop-types - Off.react/react-in-jsx-scope - Off.@next/eslint-plugin-nexteslint-plugin-turbo@vitest/eslint-plugineslint-plugin-jesteslint-plugin-prettier[!IMPORTANT] Prettier is not enabled by default in our recommended configs. The official advice by both the Prettier team and the ESLint team is to not integrate Prettier rules into your ESLint config. Formatters should be something you forget about; lots of red squiggly lines in your editor can be distracting as well as less performant.
However, it is expected that users implement Prettier into their workflow at some point. Ideally users integrate Prettier into their editors, or you run Prettier as a file watcher.
Alternatively (or in addition to), you can conditionally enable Prettier during CI to ensure committed code is formatted correctly:
// eslint.config.js
// This is the common CI ennvar, however, adjust to your system
const isCI = process.env.CI;
export default linters.load(
...
// Enable Prettier in CI only
isCI && {
// No files array will lint all files
extends: linters.configs.recommended.prettier,
},
...
};
[!NOTE] Prettier should be enabled as your last config so that it can override any rules it might conflict with.
This table details which rules have been added or removed from the last major release (also compatibility with Biome given it looks like a promising upgrade from ESLint).
If Dependabot is configured on your project, it will create Pull Requests to update @krakentech/eslint-config automatically when we update it, so you never need to worry about linting dependencies again.
Following instructions for @changesets/cli;
Whenever you make a change, run pnpm changeset to generate documentation and include this in your last commit.
When you're ready to release changes (not necessarily after each change), follow the documentation from the changesets package above.
You may need to create a .npmrc file in packages/eslint-config containing the following. The authToken can be found under "NPMJS - Global Write access token" in the KT - Vendors 1Password entry:
@krakentech:registry=https://registry.npmjs.org/
//registry.npmjs.org/:_authToken=WRITE_ACCESS_TOKEN_FROM_1PASSWORD
To use your new release,
yarn add -D @krakentech/eslint-config@x.y.z to install the new releaseIf you have trouble, check the package hasn't been made private inadvertently. Logging into our npm organisation account is required to fix this if broken.
FAQs
A globally shareable ESLint config for Octopus Energy repositories.
We found that @krakentech/eslint-config demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Malicious Go packages are impersonating popular libraries to install hidden loader malware on Linux and macOS, targeting developers with obfuscated payloads.
Security News
Bybit's $1.46B hack by North Korea's Lazarus Group pushes 2025 crypto losses to $1.6B in just two months, already surpassing all of 2024's $1.49B total.
Security News
OpenSSF has published OSPS Baseline, an initiative designed to establish a minimum set of security-related best practices for open source software projects.