Lesson 17 / 27
Team Setup & Shared Configurations
Share one ESLint config across projects as an npm package that exports flat config arrays.
Scaling configurations
Large teams benefit from centralized ESLint configs. Extract shared rules into a package (@org/eslint-config) and use it across all projects.
Shared config package
Structure for a reusable flat-config package that exports an array.
# packages/eslint-config/package.json
{
"name": "@myorg/eslint-config",
"type": "module",
"main": "index.js",
"peerDependencies": { "eslint": "^9.0.0" }
}
// packages/eslint-config/index.js
import js from '@eslint/js';
export default [
js.configs.recommended,
{ rules: { /* team rules */ } },
];
// a project's eslint.config.js
import team from '@myorg/eslint-config';
export default [...team];
Output:
Shared ESLint config package created
Version control configs
Store shareable configs in your main repo or as separate npm packages. Version them and let teams update at their pace.
Quick check
Quick check: Why create a shared ESLint config package?
- To slow down development.
- To reduce code.
- To ensure all team projects follow the same standards.
- To rename branches
Answer
To ensure all team projects follow the same standards. — Shared configs maintain consistency across your organization and make onboarding new projects trivial.