oxc-project/oxc · warning · OxcDiagnostic

Identifier '{name}' is restricted.

Error message

Identifier '{name}' is restricted.

What it means

Diagnostic from the `id-denylist` rule (ESLint id-denylist port). The rule takes a list of forbidden identifier names; when any variable, function, parameter, or other binding is declared with (or, depending on configuration semantics, references) one of the denylisted names, this message reports it with the name substituted. The default configuration is an empty set, so the rule only fires once you supply a denylist.

Source

Thrown at crates/oxc_linter/src/rules/eslint/id_denylist.rs:31

        ModuleExportName, PrivateIdentifier,
    },
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};

use crate::{
    AstNode,
    context::{ContextHost, LintContext},
    rule::{Rule, TupleRuleConfig},
    rules::eslint::id_match::{
        is_dynamic_import_attribute_object_property, is_known_external_global,
        transparent_reference_parent,
    },
};

fn id_denylist_diagnostic(span: Span, name: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Identifier '{name}' is restricted.")).with_label(span)
}

fn id_denylist_private_diagnostic(span: Span, name: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Identifier '#{name}' is restricted.")).with_label(span)
}

#[derive(Debug, Default, Clone, Deserialize, Serialize)]
pub struct IdDenylist(Box<FxHashSet<String>>);

impl JsonSchema for IdDenylist {
    fn schema_name() -> String {
        "IdDenylist".to_string()
    }

    fn json_schema(r#gen: &mut SchemaGenerator) -> Schema {
        Schema::Object(SchemaObject {
            instance_type: Some(InstanceType::Array.into()),
            array: Some(Box::new(ArrayValidation {

View on GitHub (pinned to e1e7af627c)

Solutions

1. Rename the identifier to something specific to its purpose (`response` → `userResponse`, `e` → `fetchError`, `data` → `userData`).
2. Review the denylist in `.oxlintrc.json` and remove entries that are too broad for the codebase, or keep the list intentionally small and domain-driven.
3. If the name is legitimate in context (e.g. a well-known API shape), add an inline `oxlint-disable-next-line id-denylist` with a justification comment.

Example fix

// before
function save(data) {
  return api.post('/items', data);
}

// after
function save(itemDraft) {
  return api.post('/items', itemDraft);
}

// Keep the denylist intentional and small; check new names against it mechanically:
// .oxlintrc.json -> "id-denylist": ["error", "data", "err", "foo", "bar"]
// CI: oxlint src/ fails before merge when a denied name appears.

When it happens

Trigger: Configure the rule with names, e.g. `{ "id-denylist": ["error", "data", "response", "e"] }`, then declare or use an identifier with a matching name: `function handle(data) {}`, `const response = await fetch(url);`, `catch (e) {}`. The diagnostic function at crates/oxc_linter/src/rules/eslint/id_denylist.rs:31 formats the identifier into the message.

Common situations: Teams banning vague names like `data`, `result`, `item`, `err`, `e` to improve readability; monorepos sharing one lint config where a new denylist entry breaks many files at once; upgrading a shared config package that added new denylisted words; the rule reporting catch parameters (`catch (e)`) which is a frequent friction point.

Related errors

• Identifier '#{name}' is restricted.
• A constructor name should not start with a lowercase letter.
• A function with a name starting with an uppercase letter sho
• Identifier name is too short (< {config_min}).
• `VirtualFree` failed during cleanup: {err}

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/4cc1a04ad8d7acdc. Report an issue: GitHub.