oxc-project/oxc · warning · OxcDiagnostic

`alert`, `confirm` and `prompt` functions are not allowed

Error message

`alert`, `confirm` and `prompt` functions are not allowed

What it means

Diagnostic from the `no-alert` rule. It disallows calls to the browser globals `alert`, `confirm`, and `prompt` (crates/oxc_linter/src/rules/eslint/no_alert.rs:64 matches exactly these three names) because they are blocking, obtrusive UI primitives and `alert` is a common leftover debugging tool. The check resolves the identifier as a global reference, and shadowed local variables assigned from those names can still be flagged depending on scoping resolution — the rule docs explicitly show the shadowing case.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_alert.rs:11

use oxc_ast::{AstKind, ast::Expression};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::ScopeId;
use oxc_span::{GetSpan, Span};
use oxc_str::Ident;

use crate::{AstNode, context::LintContext, rule::Rule};

fn no_alert_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("`alert`, `confirm` and `prompt` functions are not allowed")
        .with_help("Use a custom UI instead")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoAlert;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Disallow the use of `alert`, `confirm`, and `prompt`.
    ///
    /// ### Why is this bad?
    ///
    /// JavaScript’s `alert`, `confirm`, and `prompt` functions are widely considered to be obtrusive as UI elements and should be replaced by a more appropriate custom UI implementation.
    /// Furthermore, `alert` is often used while debugging code, which should be removed before deployment to production.
    ///
    /// ### Examples

View on GitHub (pinned to e1e7af627c)

Solutions

1. Remove leftover debugging calls; replace temporary debugging with `console.log`/`console.debug` or a conditional logger.
2. For real user-facing flows, swap in your product's UI (toast, modal component) as the help text ('Use a custom UI instead') suggests.
3. If the calls are intentional (kiosk/WebView tooling), disable the rule inline (`oxlint-disable no-alert`) or in the config for those files.

Example fix

// before
function onDelete(item) {
  if (!confirm('Delete?')) return;
  api.remove(item.id);
}

// after
function onDelete(item) {
  openConfirmDialog({ message: 'Delete?', onConfirm: () => api.remove(item.id) });
}

// CI: oxlint --rule no_alert src/ blocks debug dialogs before merge.
// Local pre-commit hook example:
// oxlint --rule no_alert --deny-warn $(git diff --name-only --cached | grep -E '\.(js|ts)$')

When it happens

Trigger: Any call `alert('here!')`, `confirm('Are you sure?')`, or `prompt("What's your name?", 'John Doe')` anywhere in linted source, including debug leftovers and code that rebinds the name (`var alert = myCustomLib.customAlert; alert();` — shown in the rule's own docs at crates/oxc_linter/src/rules/eslint/no_alert.rs:49-50). The rule has no options.

Common situations: Debug `alert()` calls accidentally committed before deployment; browser-only code linted together with shared code; libraries wrapping native dialogs where the rule flags even intentional usage; Electron/webview apps where blocking dialogs are considered acceptable UX but the shared config forbids them.

Related errors

• Expected Symbol to have a description.
• Empty array binding pattern
• Empty object binding pattern
• Expected error to be handled.
• Do not use @ts-{ts_comment_name} because it alters compilati

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