Composable by default
Start with the base package, add explicit framework packages, and layer in only the integrations your project actually needs.
DX-first documentation for @santi020k/eslint-config-basic, a composable ESLint 9/10+ toolkit for JavaScript and TypeScript teams shipping React, Next.js, Astro, Vue, Svelte, Solid, Angular, NestJS, Expo, Qwik, and Remix.

Base
JavaScript, TypeScript, runtime presets, and strict mode.
Scale
12 frameworks, 26 integrations, docs, API, and playgrounds.
Why this library exists
@santi020k/eslint-config-basic was built for the kind of projects teams actually maintain: JavaScript and TypeScript apps, framework-heavy frontends, monorepos, and codebases that need strong defaults without turning every setup into a custom linting project.
This docs site is the fastest way to choose the right package, compose a flat config, and roll the setup across React, Next.js, Astro, Vue, Svelte, Solid, Angular, NestJS, Expo, Qwik, Remix, and modern tooling.
Explicit packages for the stacks you actually ship, not vague one-size-fits-all presets.
Tailwind CSS, Vitest, Playwright, Markdown, Prettier, Storybook, i18next, and more.
Auto-detection, strict mode, real playgrounds, and docs that stay tied to the working codebase.
Built around modern ESLint workflows instead of legacy config patterns teams are trying to leave behind.
Learn the base package, the first config file, the auto-detection model, and the right next page for your stack.
Open guideFrameworksChoose the exact framework packageEvery supported framework has its own page with install notes, config examples, and package relationships.
Browse frameworksToolingLayer in optional integrationsLibraries, testing tools, file formats, standalone tools, and extension packs are documented in one place.
See toolingPackagesUnderstand the monorepo layoutSee what the main package owns, what lives in core or optionals, and how the repo stays composable.
Inspect packagesExamplesValidate ideas against playgroundsJump into real framework and tooling playground packages before you adopt a new stack or integration.
Open playgroundsReferenceBrowse the generated APIKeep guides, package docs, and generated reference in the same place so canonical links stay stable.
Read API docsBuild the right linting stack
Use dedicated framework packages when the runtime actually requires them. That keeps the final config readable, makes package boundaries obvious, and reduces hidden behavior for teams onboarding into an existing repo.
Instead of memorizing custom preset names, enable categories that mirror real project needs: libraries, testing, formats, standalone tools, and extension packs.
Choose the fastest path
Start with Getting Started if you are new to the library, jump to Configuration if you already know the shape of the final config, or go straight to Optional Tooling and Framework Guides when the application stack is already defined.
The generated API reference, package docs, and playground guidance all stay inside the same site so contributors, tech leads, and individual developers can move from install to real repo decisions without losing context.