oxc-project/oxc · error · OxcDiagnostic
do not access Object.prototype method {method_name:?} from t
Error message
do not access Object.prototype method {method_name:?} from target object What it means
Lint diagnostic from eslint/no-prototype-builtins: hasOwnProperty, isPrototypeOf, or propertyIsEnumerable was called directly on an object (obj.hasOwnProperty(k)). Objects without a prototype (Object.create(null)) or with shadowed methods throw or lie; calling from Object.prototype is always safe.
Source
Thrown at crates/oxc_linter/src/rules/eslint/no_prototype_builtins.rs:9
use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::{GetSpan, Span};
use crate::{AstNode, context::LintContext, rule::Rule};
fn no_prototype_builtins_diagnostic(method_name: &str, span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn(format!(
"do not access Object.prototype method {method_name:?} from target object"
))
.with_help(format!(
"to avoid prototype pollution, use `Object.prototype.{method_name}.call` instead"
))
.with_label(span)
}
#[derive(Debug, Default, Clone)]
pub struct NoPrototypeBuiltins;
declare_oxc_lint!(
/// ### What it does
///
/// Disallow calling some `Object.prototype` methods directly on objects.
///
/// ### Why is this bad?
///View on GitHub (pinned to e1e7af627c)
Solutions
- Use Object.prototype.hasOwnProperty.call(obj, key) as the help suggests
- Prefer Object.hasOwn(obj, key) in modern runtimes
- Use a Map or Set instead of relying on prototype-based key checks
Defensive patterns
Strategy: validation
When it happens
Trigger: Thrown at crates/oxc_linter/src/rules/eslint/no_prototype_builtins.rs:9 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/bbc0255b531c6930.
Report an issue: GitHub.