Repository navigation
Bug: use-baseline exceeds maximum call stack size if node package < 26.0.0 is installed #574
Description
Environment
ESLint version: 10.11.0
@eslint/css version: 2.0.0
Node version: 24.21.0 (Node.js, not node the package)
npm version: 11.15.0
Operating System: Windows 11 Enterprise
node (the package) version: 25.9.0
Which language are you using?
stylesheet
What did you do?
Configuration
import { defineConfig, globalIgnores } from "eslint/config";
import css from "@eslint/css";
export default defineConfig([
// Including or exluding globalIgnores() makes no difference:
globalIgnores(["node_modules"]),
{
files: ["**/*.css"],
language: "css/css",
plugins: { css },
rules: { "css/use-baseline": "warn" },
},
]);/* Any .css file, even empty, reproduces the bug. */Repro Steps
As-is
- Run
npm cito install@eslint/css@2.0.0andnode@25.9.0. - Run
npm run lintto run eslint, and it should crash from exceeding maximum call stack size.
This happens when there is any .css file in the project, even if completely empty.
This only occurs with the "css/use-baseline" rule active ("warn" or "error"), seemingly regardless of any rule options.
Including or excluding the ESLint globalIgnores() for "node_modules" makes no difference.
Different @eslint/css and node Versions
There are interesting combinations of @eslint/css and node versions which do NOT reproduce the issue.
(Use npm install -D --save <packageName>@<packageVersion> to install a specific version, replacing the current version if there is one. Use npm uninstall <packageName> to uninstall a package. Use npm ci after either to doubly ensure the correct version is installed for a test.)
@eslint/css@1.4.0andnode@25.9.0does NOT reproduce the issue, meaning the latest update to @eslint/css introduced it (even if transiently).@eslint/css@2.0.0andnode@26.0.0does NOT reproduce the issue, meaning recent changes to node are likely involved too.@eslint/css@2.0.0and uninstalling node (the package) does NOT reproduce the issue.
# 3 perplexes me, because from my understanding, simply installing a user package shouldn't affect the behavior of dependency packages.
What did you expect to happen?
Running eslint on the project should complete without error.
What actually happened?
Running eslint fails with the following error:
RangeError: Maximum call stack size exceeded
at Config.validateRulesConfig (C:\<path>\repos\BugReport\node_modules\eslint\lib\config\config.js:759:5)
at new Config (C:\<path>\repos\BugReport\node_modules\eslint\lib\config\config.js:581:9)
at [finalizeConfig] (C:\<path>\repos\BugReport\node_modules\eslint\lib\config\flat-config-array.js:212:10)
at FlatConfigArray.getConfigWithStatus (C:\<path>\repos\BugReport\node_modules\@eslint\config-array\dist\cjs\index.cjs:1411:55)
at FlatConfigArray.getConfig (C:\<path>\repos\BugReport\node_modules\@eslint\config-array\dist\cjs\index.cjs:1429:15)
at entryFilter (C:\<path>\repos\BugReport\node_modules\eslint\lib\eslint\eslint-helpers.js:325:27)
at async NodeHfs.<anonymous> (file:///C:/<path>/repos/BugReport/node_modules/@humanfs/core/src/hfs.js:574:24)
at async NodeHfs.walk (file:///C:/<path>/repos/BugReport/node_modules/@humanfs/core/src/hfs.js:614:3)
at async globSearch (C:\<path>\repos\BugReport\node_modules\eslint\lib\eslint\eslint-helpers.js:366:20)
at async Promise.allSettled (index 0)Link to Minimal Reproducible Example
https://github.com/MewNXP/eslint-css_use-baseline_BugReport
Participation
- I am willing to submit a pull request for this issue.
AI acknowledgment
- I did not use AI to generate this issue report.
- (If the above is not checked) I have reviewed the AI-generated content before submitting.
Additional comments
I have a project that separately has issues with node >= 26.0.0, so for now I need to have node@25.9.0 installed and have reverted to @estlint/css@1.4.0 in the meantime. I didn't think it was possible for simply having a package installed to affect a dependency package's behavior!
Metadata
Metadata
Labels
Type
Projects
- StatusShow more project fieldsImplementing
Activity
eslint-github-bot commentedon Sep 22, 2026
👋 Hi! This issue is being addressed in pull request #575. Thanks, @Copilot!
nzakas commentedon Sep 23, 2026
Thanks, it looks like we're building up what could potentially be a giant schema for the rule and that appears to be the problem. We'll take a look.