# eslint-plugin-angular: ESLint rules for AngularJS projects that still run

> eslint-plugin-angular ships the rules that catch AngularJS mistakes, including several taken straight from John Papa's style guide, and it has been kept current with flat config, ESLint 9 and 10, Vitest and pnpm. The plugin is MIT licensed in package.json, and the tooling around it is more current than the framework it lints.

**EmmanuelDemey/eslint-plugin-angular** — ESLint plugin for AngularJS applications

- Repository: https://github.com/EmmanuelDemey/eslint-plugin-angular
- Website: https://www.npmjs.com/package/eslint-plugin-angular
- Stars: 619 · Forks: 126
- Language: JavaScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/emmanueldemey-eslint-plugin-angular

## The plugin targets AngularJS and says so plainly

The scope statement in the README is blunt. This repository gives access to new rules for ESLint, and you should use it only if you are developing an AngularJS application. That single sentence removes the most common confusion around a plugin with this name, because there is a separate and much larger ecosystem of tooling for Angular 2 and later. The rules here understand the AngularJS API surface: modules, controllers, scopes, directives, services and the injector. The categories the README lists start with Possible Errors, rules that detect patterns that can lead to errors, and continue with Best Practices. A concrete example of the first category is no-private-call, which disallows the use of internal AngularJS properties prefixed with $$, and another is avoid-scope-typos, which catches mistakes when naming methods defined on the scope object. The plugin is published on npm as eslint-plugin-angular and the package description is ESLint rules for AngularJS projects.

## Module getter and setter rules encode the style guide

Several rules map directly onto John Papa's AngularJS style guide, and the README links each rule to the corresponding section since the 0.0.4 release. module-getter disallows referencing a module with a variable and requires the getter syntax angular.module('myModule'), linked to rule y022 of the guide, and module-setter disallows assigning modules to variables, linked to y021 and paired with the getter rule. Best Practices rules include component-limit, which limits the number of Angular components per file and maps to y001, controller-as-route, which requires the use of controllerAs in routes or states and maps to y031, and controller-as-vm, which requires a capture variable for this in controllers and maps to y032. The point of this set is that the style guide is not a document your team has to remember. It becomes lint errors, and each rule links back to the guideline section that explains the reasoning.

## Flat config support with two ways to switch the rules on

The plugin works with the flat config format, and the README documents two routes. The first installs the plugin and then spreads a shareable config into your eslint.config.mjs:

```javascript
    import { defineConfig } from "eslint/config";
    import angular from "eslint-plugin-angular";

    export default defineConfig([{
      plugins: {
        angular
      },
      rules: {
        ...angular.configs.johnpapa.rules
      }
    }]);
```

The second route registers the plugin only and lets you pick rules yourself. The README notes that every rule defined in the plugin has to be prefixed with angular/, so a single rule is enabled like this:

```javascript
    import { defineConfig } from "eslint/config";
    import angular from "eslint-plugin-angular";

    export default defineConfig([{
      plugins: {
        angular
      },
      rules: {
        "angular/controller-name": "error"
      }
    }]);
```

Installing the plugin is a normal dev dependency, either with npm or with pnpm as the README shows in both installation steps. Which route you take matters for a legacy codebase: the shareable config turns on a whole opinionated set at once, while the manual route lets you adopt rule by rule as you fix the existing violations.

## The project lints itself with oxlint rather than ESLint

The package.json scripts reveal a deliberate shift in the plugin's own toolchain. The lint script is oxlint rather than eslint, and the README explains why, calling it a fast code quality check using OXC, the Rust based linter, across all JavaScript files, exiting 0 on success and 1 on lint errors. The devDependencies show ESLint itself pinned at ^10.7.0 as well as oxlint at ^1.73.0, so both tools are present, ESLint as the thing the plugin plugs into and oxlint as the thing that checks the plugin's own source. Other devDependencies are telling as well: Vitest for the test runner, chai and chai-spies for assertions and spies, espree as the parser and lodash for utility work. The peerDependencies field pins eslint to ^9.32.0 or ^10.0.0, which matches the README statement that ESLint 9.32.0 and later 9.x releases as well as ESLint 10.x are supported.

## pnpm test is the gate that CI runs

There is one command that matters for contributors, and the README is explicit about what it does. The test script runs lint, then generate:docs, then test:run, in that order, stopping immediately if any step fails. The README says this is what CI runs and that you should ensure it passes before committing. The test:run script executes vitest run with coverage, and the README states it runs all 2141+ tests, generating coverage in LCOV and text formats with a browsable report at coverage/lcov-report/index.html. Development itself expects Node.js 24.18.0 and pnpm 11.12.0, with the README listing both a global npm install of pnpm and the Corepack route as the alternative:

```bash
corepack enable
```

```bash
corepack install --global pnpm@11.12.0
```

A repository with more than two thousand tests and a fail-fast pipeline is a reasonable signal about how the rule set is protected against regressions, which matters when the rules themselves are the public interface of the package.

## Rule documentation is generated, not written by hand

The docs are produced by a script rather than maintained manually. The generate:docs command runs node scripts/docs.js, and the README says it updates README.md with the rule descriptions and creates individual markdown files in docs/rules/ for each rule, and that it should be run after adding or modifying rules. That is the mechanism behind the rule list in the README, where each entry links to a file under docs/rules/ such as component-limit.md or module-getter.md. The repository layout supports the same picture, with a rules/ directory holding the implementations, a specs/ directory, a test/ directory, an examples/ directory with one file per rule such as examples/controller-as-vm.js, and a docs/ directory for the generated pages. The examples directory is worth a look before enabling a rule, because it shows the code that triggers the rule and the code that satisfies it.

## MIT in package.json, one release since 2021, a push in July 2026

The licence situation is a small contradiction worth resolving rather than repeating. No licence identifier is listed at the repository level, while package.json declares MIT in its licence field and the project publishes to npm under that name. The MIT terms are the ones that apply to the distributed package. The release history is sparse by npm standards: version 4.0.1 in 2019, 4.1.0 in 2021, and then 5.0.0 on 2025-08-03, with the last push on 2026-07-12. The gap is explained by the major version jump, since 5.0.0 is where flat config and the ESLint 9 and 10 support arrive, but the release cadence itself is slow and the maintainers listed in package.json are three individuals rather than a company. That is a normal shape for a plugin that serves a framework whose own successor moved on years ago, and it means you should read the rules you enable rather than assume a stream of fixes.

## Conclusion

Adopt eslint-plugin-angular if you still maintain AngularJS 1.x code and want the category rules, the module getter and setter rules and the John Papa derived conventions enforced by one plugin that works with the current flat config format and current ESLint versions. Do not adopt it for an Angular 2 and later codebase, since the rules are written against the AngularJS API. Verify first that your ESLint version satisfies the peer dependency of ^9.32.0 or ^10.0.0, decide whether you want the whole johnpapa ruleset or individual angular/ prefixed rules, and run pnpm test once in your fork so that the oxlint, documentation generation and Vitest steps all pass before you wire the plugin into a shared config.

## FAQ

### What does eslint-plugin-angular do and who is it for?

It is an ESLint plugin for AngularJS applications, providing rules that detect errors, prescribe best practices and enforce conventions. The README says you should use it only if you are developing an AngularJS application.

### How do I install eslint-plugin-angular and enable its rules?

Install eslint and eslint-plugin-angular as dev dependencies, then register the plugin in eslint.config.mjs, either spreading angular.configs.johnpapa.rules for the whole set or enabling individual rules with the angular/ prefix.

### Which ESLint versions does eslint-plugin-angular support?

The README states that ESLint 9.32.0 and later 9.x releases as well as ESLint 10.x are supported, and the peerDependencies in package.json pin eslint to ^9.32.0 or ^10.0.0.

### How are the rules tested and documented?

The test script runs Vitest with coverage and the README states it executes all 2141+ tests, while the docs are generated by node scripts/docs.js, which updates README.md and writes a page per rule under docs/rules/. The examples/ directory holds one file per rule.

### What is the licence of eslint-plugin-angular?

package.json declares the MIT licence for the published package, while the repository metadata does not list a licence identifier. The project is published on npm as eslint-plugin-angular and version 5.0.0 was released on 2025-08-03.

## Sources

- [EmmanuelDemey/eslint-plugin-angular on GitHub](https://github.com/EmmanuelDemey/eslint-plugin-angular)
- [Issues](https://github.com/EmmanuelDemey/eslint-plugin-angular/issues)
- [Project website](https://www.npmjs.com/package/eslint-plugin-angular)
- [README](https://github.com/EmmanuelDemey/eslint-plugin-angular/blob/master/README.md)
- [Releases](https://github.com/EmmanuelDemey/eslint-plugin-angular/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/emmanueldemey-eslint-plugin-angular