The @angular-eslint/schematics package is the official Angular CLI schematics that wire ESLint into an Angular workspace, and it is a well-maintained, low-risk dev dependency when you install it the standard way. It's part of the angular-eslint project, which is the community-standard replacement for the long-deprecated TSLint tooling, and it's the package that runs when you type ng add @angular-eslint/schematics. The security questions worth asking aren't whether the code is hostile; it's a widely used, actively released package with the major line in the 21.x range as of mid-2025. The real questions are about what it does to your project during install and how you keep its dependency tree clean.
Here's what a practical security review of adopting it looks like.
What the package actually does
@angular-eslint/schematics is a set of Angular CLI schematics. Schematics are code generators and modifiers that the Angular CLI runs to scaffold or update a workspace. This particular package adds and configures everything needed to lint an Angular project with ESLint: it installs the related angular-eslint packages, creates the ESLint config, and adds a lint target to your angular.json or project config. You invoke it once:
ng add @angular-eslint/schematics
That single command modifies files in your workspace, which is the first thing a security-minded engineer should register. A schematic is not a passive library you import; it's code that runs with your permissions and edits your project. That's expected behavior for this package, but it's the reason to source it only from the official npm scope and to review the changes it makes.
The install runs code by design
Unlike a runtime library, the whole point of ng add is to execute a schematic that writes to disk. When you run ng add @angular-eslint/schematics, the CLI resolves the package, runs its ng-add schematic, and the schematic edits your configuration and installs peer packages. This is legitimate, but treat it the way you'd treat any code-executing install:
- Run it on a branch, then review the diff before committing. You should see new ESLint config files, changes to your project config, and additions to
devDependenciesinpackage.json. Nothing should touch application source logic. - Confirm the package name exactly. The scoped name
@angular-eslint/schematicsis the correct one; be wary of unscoped look-alikes. Scoped official packages are harder to typosquat, which is one reason the Angular team publishes under the@angular-eslintscope. - Pin the resolved versions in your lockfile so a later
npm installcan't silently pull a different build.
After it runs, the ongoing footprint is just ESLint and its plugins as dev dependencies. They don't ship to production, which meaningfully lowers the risk profile compared to a runtime dependency.
Version alignment is a real gotcha
The most common friction with @angular-eslint/schematics isn't security, it's version mismatch, and mismatch has a security angle. The angular-eslint packages track your Angular major version. If ng add pulls a schematics version that doesn't match your Angular CLI, you get errors, and the tempting fix is to force-install or pin an old version to make the error go away. Don't reach for a stale pin as a workaround, because an old angular-eslint line eventually stops receiving updates to its bundled ESLint and TypeScript-ESLint dependencies, and that's where a known vulnerability would surface. Match the schematics major version to your Angular major version, and upgrade both together.
Where the actual vulnerability risk lives
ESLint tooling pulls in a sizable transitive tree: the ESLint core, typescript-eslint, various plugins, and their own dependencies. That tree, not the schematics package itself, is the realistic place a CVE shows up. Dev dependencies are often under-scanned precisely because "they don't run in production," but they run on developer machines and in CI, which is a foothold attackers actively target through the build pipeline.
Keep the tooling current and scanned. Running your dependency audit against dev dependencies too, not just production ones, is the right default:
npm audit
An SCA tool such as Safeguard can flag a vulnerable transitive package inside the ESLint toolchain, including ones you never added directly, so you can bump or override it. The general principle from our npm security best practices applies here: a dev dependency that executes in CI deserves the same scrutiny as a runtime one.
Safe adoption checklist
Adopting @angular-eslint/schematics safely is straightforward. Install it with ng add from the official scoped package on a branch, review the resulting diff before committing, and confirm nothing unexpected changed. Match the schematics major version to your Angular major version and upgrade them together rather than pinning a stale build to dodge an error. Pin resolved versions in your lockfile, keep the full ESLint toolchain patched, and include dev dependencies in your vulnerability scanning. Done that way, it's exactly what it claims to be: the standard, safe way to get ESLint running in an Angular workspace.
The takeaway mirrors the broader pattern with official tooling packages. The schematic itself is trustworthy and the code it runs is expected. Your job is to review what it changes, keep the version aligned, and scan the dependency tree it brings along.
FAQ
Is @angular-eslint/schematics safe to install?
Yes. It's the official Angular ESLint setup package, actively maintained under the @angular-eslint scope. Install it with ng add, review the diff it produces, and keep it version-aligned with your Angular major version.
Does ng add @angular-eslint/schematics run code?
Yes, by design. The ng add command executes the package's schematic, which edits your workspace config and installs ESLint dev dependencies. Run it on a branch and review the changes before committing, as you would with any code-executing install.
Why does @angular-eslint/schematics fail to install or show version errors?
Almost always a version mismatch. The angular-eslint packages track your Angular major version. Match the schematics major version to your Angular CLI version and upgrade both together rather than forcing a stale pin.
Do I need to scan @angular-eslint/schematics for vulnerabilities?
Scan its transitive tree, not just the package itself. The ESLint core, typescript-eslint, and plugins are where a CVE would appear. Include dev dependencies in your audits, since they run in CI and on developer machines.