oxc-project/oxc · warning · OxcDiagnostic

Prefer `{good_method}` over `{bad_method}`

Error message

Prefer `{good_method}` over `{bad_method}`

What it means

Lint diagnostic from oxlint's `unicorn/prefer-code-point` rule. JavaScript strings are UTF-16, so `charCodeAt(i)`/`fromCharCode(n)` operate on 16-bit code units and mis-handle characters outside the BMP (emoji, CJK extensions) that are stored as surrogate pairs. `codePointAt(i)`/`fromCodePoint(n)` operate on Unicode code points. The rule flags the code-unit APIs; `{good_method}`/`{bad_method}` interpolate as `codePointAt`/`charCodeAt` or `fromCodePoint`/`fromCharCode`.

Source

Thrown at crates/oxc_linter/src/rules/unicorn/prefer_code_point.rs:9

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;

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

fn prefer_code_point_diagnostic(span: Span, good_method: &str, bad_method: &str) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Prefer `{good_method}` over `{bad_method}`"))
        .with_help(format!("Unicode is better supported in `{good_method}` than `{bad_method}`"))
        .with_label(span)
}

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

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Prefer usage of `String#codePointAt` over `String#charCodeAt`.
    /// Prefer usage of `String.fromCodePoint` over `String.fromCharCode`.
    ///
    /// ### Why is this bad?
    ///
    /// Unicode is better supported in [`String#codePointAt()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/codePointAt) and [`String.fromCodePoint()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/fromCodePoint).
    ///
    /// [Difference between `String.fromCodePoint()` and `String.fromCharCode()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/fromCodePoint#compared_to_fromcharcode)

View on GitHub (pinned to e1e7af627c)

Solutions

1. Replace `str.charCodeAt(i)` with `str.codePointAt(i)` and `String.fromCharCode(n)` with `String.fromCodePoint(n)`.
2. Audit iteration: use `for (const ch of str)` (code points) instead of index loops when converting.
3. If code-unit semantics are intentional (UTF-16 encoding, Base64, hash functions like FNV/djb2 over code units), suppress with `// oxlint-disable-next-line unicorn/prefer-code-point` and state why — changing those breaks the algorithm.
4. Disable the rule for codec/hash-heavy files via `.oxlintrc.json` overrides if most calls are intentionally code-unit based.

Example fix

// before
const first = str.charCodeAt(0);
const ch = String.fromCharCode(0x1F600);

// after
const first = str.codePointAt(0);
const ch = String.fromCodePoint(0x1F600); // U+1F600 emoji

// oxlint --filter unicorn/prefer-code-point src/
// CI gate: oxlint --deny-warnings src/

When it happens

Trigger: Calls to `str.charCodeAt(index)` or `String.fromCharCode(num[, ...nums])` anywhere in scanned code — member call on `charCodeAt`, or static `fromCharCode` call. Reported during oxlint runs when the rule is enabled (unicorn category, style/pedantic group).

Common situations: String-indexing utilities (capitalizers, cipher/hash ports, char walkers) written with charCodeAt. Breaks visibly once input contains emoji or rare CJK characters — `charCodeAt` yields surrogate halves, producing mojibake. Surfaces in bulk when the unicorn category is turned on, including in vendored/ported code.

Related errors

• Use uppercase characters for the value of the escape sequenc
• Use Unicode escapes instead of hexadecimal escapes.
• Prefer `.at()` over `{method}`.
• Prefer the spread operator (`...`) over {bad_method}
• Template placeholders will not interpolate in regular string

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