refactor(linter): resolve globals from env on build

[Sysix]

Refactored how env and globals worked together. Before we checked each individual entry if it is enabled/disabled, but they are working "hand in hand". This was a problem for overriding global with env. An example:

{
  "globals": {
    "window": "off"
  },
  "overrides": [
   {
      "files": ["*.ts"],
      "env": {
         "browser": true
       }
    }
  ]
}

This config would tell the lint rule that window is still off, but in real we re-enabled it with the env setting.

---

Separated to logic to resolve the globals at the beginning and avoiding to have a "OxlintEnv" instance in the resolved config. We could probably rename OxlintEnv to OxlintrcEnv now.

[Sysix]

• fix(linter): merge env from extended config files #20088
• refactor(linter): resolve globals from env on build #20100 👈 (View in Graphite)
• fix(linter): check globals entry for no-undef, only check es2026 globals for no-extend-native and no-constant-binary-expression #20089
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent changes, fast-track this PR to the front of the merge queue

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

Merging this PR will not alter performance

✅ 53 untouched benchmarks
⏩ 3 skipped benchmarks¹

---

_{Comparing 03-07-refactor_linter_resolve_globals_from_env_on_build (7f99530) with main (a9acb2b)}

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Copilot]

Pull request overview

Refactors linter configuration handling so that environment presets (env) are resolved into concrete globals during config build time, removing runtime env lookups in linting/context code.

Changes:

• Remove env from LintConfig/ContextHost and stop checking enabled envs at lint-time (globals are expected to be pre-resolved).
• Resolve env presets into OxlintGlobals when building LintConfig and when resolving overrides.
• Update/add unit tests to assert env-to-globals resolution and override behavior.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
crates/oxc_linter/src/external_linter.rs	Adjusts the serialized config payload sent to JS plugins to no longer include envs (now globals-only).
crates/oxc_linter/src/context/mod.rs	Removes env-based global resolution from LintContext global queries.
crates/oxc_linter/src/context/host.rs	Removes env() accessor from ContextHost.
crates/oxc_linter/src/config/mod.rs	Drops env from LintConfig and resolves env → globals during From<Oxlintrc>.
crates/oxc_linter/src/config/globals.rs	Adds internal insertion helper to support env → globals expansion.
crates/oxc_linter/src/config/env.rs	Implements env → globals expansion logic (override_globals).
crates/oxc_linter/src/config/config_store.rs	Removes env override merging; overrides now apply via pre-resolved globals.
crates/oxc_linter/src/config/config_builder.rs	Resolves base + override env/global settings into a single globals map; adds tests for override behavior.

[Copilot]

Pull request overview

Copilot reviewed 20 out of 23 changed files in this pull request and generated 3 comments.

[Copilot]

OxlintEnv::override_globals currently inserts GlobalValue::Off for every global in an env when that env is set to false. This changes semantics vs the previous lookup-based approach: if a global is provided by multiple envs (e.g. setTimeout exists in both node and browser), disabling one env can incorrectly force that global to off even though another enabled env still provides it. Consider computing resolved globals as the union of enabled envs (ignore disabled envs), then apply explicit globals overrides last; for overrides that disable envs, this likely requires recomputing the resolved globals for that override rather than representing env: false as globals: off entries.

Suggested change

	let Some(globals_entries) = GLOBALS.get(name) else {
	continue;
	};
	for (env, supported) in globals_entries.entries() {
	if *active {
	globals_to_override.insert(env.to_string(), GlobalValue::from(*supported));
	} else {
	globals_to_override.insert(env.to_string(), GlobalValue::Off);
	}
	// Only enabled environments contribute globals; disabled envs are ignored here.
	if !*active {
	continue;
	}
	let Some(globals_entries) = GLOBALS.get(name) else {
	continue;
	};
	for (env, supported) in globals_entries.entries() {
	globals_to_override.insert(env.to_string(), GlobalValue::from(*supported));

[Copilot]

LintConfig::from expands env presets into OxlintGlobals, which can make config.globals extremely large (builtins + enabled envs). This map is cloned in Config::apply_overrides and serialized per-file for JS plugins (see crates/oxc_linter/src/config/config_store.rs and crates/oxc_linter/src/lib.rs), so this change likely introduces a significant per-file CPU/memory regression. Consider caching a pre-serialized globals JSON per resolved config, using shared/immutable maps (e.g. Arc-backed), or keeping a more compact representation for builtins/env presets when communicating with JS.

[Sysix]

@overlookmotel I am afraid this is a real problem for JS side? The snapshots-diff looks big for "node": true.
But in my opinion there should be no concept of "env" for the lint context. This is for me only a helper section to avoid defining all globals per line. With ESLint flat config and our js config, most users are using the globals npm package with destructruring like {globals: {...npm-globals['vue'], ...npm-globals['node']}.
So maybe this is at the end already a problem and did get only shown by the refactoring?