nuxt/eslint: three packages for linting a Nuxt project

A monorepo of three published packages

The repository describes itself as a collection of ESLint-related packages for Nuxt, providing project-aware, easy-to-use, extensible and future-proof integrations, and the README points to the documentation at eslint.nuxt.com for details.

The packages are listed with the two things a reader needs most, which package it is and what it is for:

- [@nuxt/eslint](./packages/module) - Nuxt module generating project-aware ESLint config
- [@nuxt/eslint-config](./packages/eslint-config) - Static ESLint Config
- [@nuxt/eslint-plugin](./packages/eslint-plugin) - ESLint Plugin

Each one lives in its own directory under `packages/`, and each is published separately to npm under the `@nuxt` scope. The root package is marked private, so the repository itself is never installed; the installable artefacts are the three packages inside it.

The most important structural fact is that these are alternatives, not layers. The module and the static config both solve the same problem, which is giving you an ESLint configuration, and the plugin is a set of rules that can sit on top of whichever one you choose. A team that adds the module does not then add the static config as well.

That distinction is what the README's word project-aware is doing work on. A static config is a file you install and extend by hand, and it has to be kept in step with the project yourself. A generated config is produced from the project as the module understands it, so the rules and the ignored paths follow the framework's own view of the source tree.

Generated config, static config, or rules on their own

The three packages split along the lines of how much you want the framework involved.

The module, @nuxt/eslint, is the Nuxt module generating a project-aware ESLint config. It runs as part of a Nuxt application, and it is the package to reach for when you want the configuration to reflect the project rather than a file you wrote once.

The static config, @nuxt/eslint-config, is a plain ESLint config you install and use. There is no Nuxt module involved, so nothing is generated and nothing has to agree with your application at build time. That is the lower-friction option, and it is the one to pick if your project already has a flat config, if you lint files outside the Nuxt build, or if you want a configuration that behaves identically in every context.

The plugin, @nuxt/eslint-plugin, is the ESLint plugin. It carries rules, and it is usable with either of the other two, or with a configuration you built yourself. The repository's own lint command uses the root eslint.config.js, and the plugin is a workspace dependency of the root package, so the project dogfoods its own rules.

The practical question for a new user is therefore simple: do you want the config generated, do you want a config you own, or do you only want the rules. The documentation site is where the differences between the packages are spelled out, and the README deliberately sends you there rather than repeating it.

A pnpm workspace with a version catalogue

The repository is a pnpm workspace, and the tooling choices in the root manifest are modern in a way that affects how you work on it.

The package manager is pinned:

  "packageManager": "[email protected]",

and the root is private with a version of 1.17.0. There is a pnpm-workspace.yaml and a pnpm-lock.yaml at the root, and the dependencies in the manifest are declared through a catalogue rather than by version, with entries such as `catalog:docs`, `catalog:dev`, `catalog:prod` and `catalog:types`.

That catalogue is worth understanding before you open a pull request. It means the versions of shared dependencies, the documentation tooling, the lint tooling and the test tooling are declared once for the whole workspace and referenced by name everywhere else. A change to the version of eslint or of vitest is a single edit in the catalogue rather than an edit in every package that uses it, and it cannot drift between packages.

The resolutions block shows the mechanism at work, pinning @nuxt/ui to a specific version for the whole workspace. That is a common pattern in a documentation site that pulls in a large component library, where an unpinned transitive change would otherwise alter how the docs look.

The workspace layout follows the same logic, with `packages/` for the published packages, a `playground/` directory, a `docs/` directory, and the `docs`, `dev`, `prod` and `types` catalogue groups lining up with how the packages are used.

Build, stub, test, lint and release, all as npm scripts

The root manifest's scripts describe the whole development loop, and they are the clearest picture of what the repository is for a contributor.

The build and stub targets are recursive across the workspace, `pnpm run -r build` and `pnpm run -r stub`, which is the usual pattern for a monorepo where each package is built with unbuild and stubbed during development. The test script is `vitest run`, and the typecheck script is `tsc --noEmit`.

The lint scripts are the ones that matter for a linting project:

    "lint": "eslint . -c eslint.config.js",
    "lint:fix": "eslint . -c eslint.config.js --fix",
    "lint:play": "pnpm -C playground run lint",

The explicit `-c eslint.config.js` is the flat config file at the repository root, and the playground gets its own lint run through the workspace. The `lint:play` script exists because the playground is a separate application with its own configuration, and running the root config over it would be wrong.

The release script runs bumpp against the root manifest and against the package manifests, which is a detail that tells you how versioning works here: the version number is written to the root and to every package manifest in one command, so the three published packages always carry the same version. The docs and playground have their own scripts, `pnpm -C docs run docs:dev` and `pnpm -C playground run play:dev`, so the documentation site and the example app are developed alongside the packages.

The repository lints itself, with its own plugin

A project that ships lint tooling is only credible if it runs that tooling on itself, and this one does.

The root manifest lists both @nuxt/eslint-config and @nuxt/eslint-plugin as workspace dependencies, which is the workspace protocol pointing at the packages in `packages/`. The lint script then runs eslint over the repository with the root eslint.config.js, so the config and the plugin in this repository are the ones checking the repository's own source.

The dev dependencies give a sense of the standards in force. eslint itself and eslint-plugin-pnpm come from the dev catalogue, alongside typescript-eslint and eslint-plugin-format, which is the plugin that runs a formatter inside the lint pass so that formatting is checked rather than merely suggested. jsonc-eslint-parser is there for JSON with comments, and eslint-vitest-rule-tester is the helper for testing rules, which is how a plugin's rules are verified to behave as documented.

The remaining tooling points the same way. There is a .editorconfig and a .vscode directory so that editors agree with the formatter, a renovate.json so that dependency updates are proposed automatically rather than by hand, and a taze.config.ts alongside the taze package, the accessibility checker. The repository is set up so that a contributor who opens a pull request gets the same checks the maintainers run.

MIT licensed, released on a slow cadence, still moving

The licence is MIT, with the LICENSE file at the repository root and the README pointing at it, and the badge in the README reads the same way.

The release history is unhurried. The recent versions are v1.17.0 from 2026-08-06, v1.16.0 from 2026-06-10 and v1.15.2 from 2026-02-24, so the line moves every couple of months rather than every week, which is a normal rhythm for a package set whose content is configuration and rules rather than application code.

The repository is not archived, and the last push was on 2026-10-19. So the branch is current and the published version is a little behind it, which is the normal state for a project where the version is cut deliberately by the release script.

The documentation site is the part a new user should read first. The README itself is deliberately short, a name, a one-line description, the three packages with their purposes, a link to eslint.nuxt.com and the licence. The site is where the module options, the difference between the two config packages and the rule list live, and the repository is where the build, the test suite and the history live. Understanding that split is most of what an adopter needs to know about this project, and it takes about a minute.

Editorial conclusion

nuxt/eslint fits a Nuxt team that wants the framework's own view of the project reflected in its lint rules, and that would rather have the configuration generated than maintain a flat config by hand. It is the wrong choice for a team that has already standardised on a static flat config, since the static package exists precisely for that case, and the wrong choice if you want ESLint without the Nuxt module in your build. Verify first which of the three packages you need, since the module and the static config are alternatives rather than companions, and read the documentation site rather than the repository, which is thin on usage detail.

Frequently asked questions

Official sources

1. License: MIT
2. nuxt/eslint on GitHub
3. Project website
4. README
5. Releases