eslint npm package: is it safe?

spawnExternalCommand() uses cross-spawn to execute external commands (npm init @eslint/config@latest and npx @eslint/mcp@latest). These are triggered when the user passes --init or --mcp. This is expected behavior for ESLint's CLI migration path, but it does fetch and execute remote packages from the npm registry, which introduces supply-chain risk (e.g., if @eslint/config or @eslint/mcp were compromised). Note that the commands are hard-coded, not derived from user input, mitigating injection concerns.

printResults resolves the user-supplied outputFile against process.cwd(), creates directories with mkdir(..., { recursive: true }), and writes the formatter output there. The destination is controlled by CLI input and can target arbitrary filesystem locations outside the package directory.

ESLint.fromOptionsModule(optionsURL) is invoked with a computed URL derived from user-supplied CLI options. Dynamic module loading based on runtime-constructed URLs expands the attack surface for arbitrary module resolution.

The code uses dynamic import() to load JavaScript configuration files (eslint.config.js) from paths resolved from user input. This is a required, documented behavior of ESLint, not an exfiltration or backdoor. The imported files are the user's own config files, not external or attacker-controlled remote modules.

The code deletes entries from require.cache to force re-import of config files when their mtime changes. This is intentional for hot-reloading user config and is scoped to the config file path only, with no broad cache poisoning.

The static loadJiti method dynamically imports the 'jiti' package at runtime. This is a declared optional dependency for TypeScript config support, not an undeclared or obfuscated module load.

The loadOptionsFromModule function and the import('@humanfs/node') call use dynamic imports. However, loadOptionsFromModule is designed to load a user-specified ESLint options module (a documented feature), and the @humanfs/node import is a fixed, trusted package dependency. There is no evidence of malicious intent.

mergeEnvironmentFlags reads the ESLINT_FLAGS environment variable. This is a documented ESLint feature for supplying CLI flags and does not involve credential harvesting or exfiltration.

The code writes files (output fixes) and deletes cache files. While these are expected behaviors for a linter, they involve file system operations outside the immediate package scope (writing to user-specified paths). This is standard for ESLint but could be misused if paths are attacker-controlled.

The code spawns worker threads to lint files. This is a legitimate performance feature. However, it uses SHARE_ENV which shares the environment variables with workers, potentially exposing environment variables to worker threads. This is not malicious by itself but could be a concern if workers are compromised.

The worker calls require("node:module").enableCompileCache?.() at load time. This is a Node.js API that caches compiled bytecode on disk for subsequent runs. While not inherently malicious, it writes cached V8 code to the filesystem outside the normal linting scope and executes at worker import time. It could be abused to cache or replay compiled code if paths were attacker-controlled, though here it uses default cache directories.

The load() method reads from this.filePath which is set by the caller. No path traversal from untrusted input is present; the path comes from ESLint's configuration.

The save() method writes to this.filePath, which is passed in via constructor options. This is normal for a suppressions file manager (ESLint's official suppressions feature) and the path is controlled by the calling code, not external input.

The code uses cross-spawn.sync to execute external commands ('npm --version', 'npm ls ...', 'npm bin -g'). This is a process spawning pattern. Although cross-spawn is a well-known library and the arguments are static, executing external binaries at runtime can be a security concern if the PATH or environment is manipulated. In this context it appears legitimate for gathering environment info (the code is from ESLint and clearly documented as such).

The module collects environment details including Node version, npm version, local/global ESLint versions, and OS platform/release. This is expected behavior for a CLI diagnostic utility, but it does read execution environment information. It does not read sensitive files (no .npmrc, .ssh, etc.) and does not send data externally.

The result of npm ls --depth=0 --json is parsed with JSON.parse. While not a direct vulnerability, parsing untrusted command output is a pattern to note. The parsed output is only used to extract version strings.

The code uses ModuleImporter to dynamically import ESLint plugins and parsers based on CLI-supplied names (via the --plugin and --parser options). While this is expected and intended behavior for ESLint, it allows loading and executing arbitrary modules from the filesystem or node_modules if an attacker controls CLI arguments. This is not malicious per se, but is a code execution vector if untrusted input reaches these options.

The parser option is passed directly to importer.import(), which resolves and executes an arbitrary module specified by the user. This is a normal ESLint feature but represents dynamic code loading driven by external input.