eslint-import-resolver-typescript is a development dependency that teaches ESLint how to follow TypeScript path aliases and type-only imports, and its security relevance comes from the fact that dev tooling runs with full access to your machine and CI environment. It is not a runtime library, so it never ships to production — but that is cold comfort, because build-time and lint-time code is exactly where modern supply chain attacks land.
The resolver family also includes eslint-import-resolver-node, eslint-import-resolver-webpack, and eslint-import-resolver-alias. They all plug into eslint-plugin-import to resolve module paths, and they all execute as part of your lint step. Understanding that shared model is the key to securing any of them.
Why a "just a linter plugin" is a real attack surface
The industry spent a decade obsessing over production dependencies while shipping build pipelines that npm install hundreds of dev packages, each able to run arbitrary code in postinstall scripts on developer laptops and CI runners with cloud credentials in the environment. That asymmetry is what attackers noticed.
An import resolver is a good example. It runs every time ESLint runs — pre-commit, in CI, in your editor on save. If a malicious version were published (through a compromised maintainer account or a typosquat), the payload would execute in an environment that typically holds:
- npm and registry tokens
- Cloud provider credentials for the CI job
- Source code, including secrets that should not be there but often are
So the correct mental model for eslint-import-resolver-typescript is not "harmless dev tool" but "code that runs with my CI's full privileges." That reframing drives every recommendation below.
Lock versions and verify integrity
The first control is deterministic installs. Commit your lockfile and install from it exactly:
# CI must use the lockfile as the source of truth, not resolve fresh
npm ci
npm ci fails if package.json and package-lock.json disagree, and it installs the exact resolved versions with their integrity hashes. That closes the window where a freshly published malicious patch version slips in between commit and build. Never run a bare npm install in CI for this reason.
Pin the resolver and its peers to specific versions rather than floating ranges, and review the diff whenever you bump them:
{
"devDependencies": {
"eslint-import-resolver-typescript": "3.6.3",
"eslint-plugin-import": "2.29.1"
}
}
Understand the resolver chain you configured
eslint-plugin-import lets you stack resolvers, and the order matters. A typical TypeScript project configures the TypeScript resolver alongside the node resolver:
// eslint.config or .eslintrc settings
settings: {
'import/resolver': {
typescript: { project: './tsconfig.json' },
node: { extensions: ['.js', '.jsx', '.ts', '.tsx'] },
},
},
If you also use eslint-import-resolver-alias or eslint-import-resolver-webpack, be deliberate about which one wins. From a security standpoint the risk of a sprawling resolver config is that each added resolver is another package with its own transitive tree and its own install scripts. Every resolver you add — eslint-import-resolver-node, eslint-import-resolver-webpack, eslint-import-resolver-alias — widens the dev-dependency surface. Only install the ones your project genuinely needs.
Disable install scripts you do not need
A strong blanket control for the whole dev toolchain is to block lifecycle scripts and allow-list the few that legitimately need to build native code:
# Refuse to run arbitrary install scripts by default
npm config set ignore-scripts true
Pure-JavaScript packages like the ESLint resolvers do not need a postinstall step to function, so blocking scripts costs you nothing for this class of dependency while removing the most common malware execution path. Test it in your environment, because a handful of packages (native modules) do rely on build scripts and will need explicit exceptions.
Scan dev dependencies, not just runtime ones
Many teams scope their SCA to production dependencies and never look at devDependencies. That is backwards given where the risk actually is. Point your composition analysis at the full lockfile:
# Include dev dependencies in the audit
npm audit
# or a scanner that reads the whole lockfile tree
Continuous scanning of the entire tree — dev included — is where a platform pays off, because it watches for a newly disclosed advisory against any resolver in your chain without you re-auditing by hand. Our software composition analysis product treats dev and runtime dependencies as one graph, and the DevSecOps academy has a longer walkthrough of securing build-time tooling.
FAQ
Is eslint-import-resolver-typescript a security risk?
Not inherently, but it runs as part of your lint step with full access to developer and CI environments, so a compromised version would execute in a privileged context. Treat it like any other build-time dependency: pin it, verify it, and scan it.
Does eslint-import-resolver-typescript ship to production?
No. It is a dev dependency used only when ESLint runs. The concern is build-time and CI execution, not your production bundle.
Do I need all of the eslint import resolvers?
No. Install only the resolvers your project actually uses. The TypeScript resolver plus the node resolver covers most setups; add eslint-import-resolver-alias or eslint-import-resolver-webpack only if your module resolution genuinely requires them, since each one widens your dependency surface.
How do I harden my ESLint toolchain against supply chain attacks?
Use npm ci with a committed lockfile, pin versions, set ignore-scripts where feasible, and run SCA across the full dependency tree including devDependencies so newly disclosed advisories are caught quickly.