prefer-code-point

Keywords: codePointAt, charCodeAt, Unicode, emoji, ESLint rule, auto-fix, LLM-optimized

Prefer String.codePointAt() over String.charCodeAt(). This rule is part of eslint-plugin-conventions.

Prefer String.codePointAt() over String.charCodeAt(). This rule is part of eslint-plugin-conventions.

Quick Summary

Rule Details

charCodeAt() only works for Basic Multilingual Plane characters. codePointAt() handles all Unicode including emoji.

Why This Matters

Examples

❌ Incorrect

const code = string.charCodeAt(0);  // Fails for emoji
'😀'.charCodeAt(0);  // Returns 55357 (wrong!)

✅ Correct

const code = string.codePointAt(0);  // Works for all Unicode
'😀'.codePointAt(0);  // Returns 128512 (correct!)

// Iterate over code points
for (const char of string) {
  const codePoint = char.codePointAt(0);
}

Configuration Examples

Basic Usage

{
  rules: {
    'conventions/prefer-code-point': 'warn'
  }
}

Related Rules

• prefer-dom-node-text-content - DOM text handling

Further Reading

• codePointAt() - MDN - MDN reference

Known False Negatives

The following patterns are not detected due to static analysis limitations:

Dynamic Variable References

Why: Static analysis cannot trace values stored in variables or passed through function parameters.

// ❌ NOT DETECTED - Value from variable
const value = externalSource();
processValue(value); // Variable origin not tracked

Mitigation: Implement runtime validation and review code manually. Consider using TypeScript branded types for validated inputs.

Imported Values

Why: When values come from imports, the rule cannot analyze their origin or construction.

// ❌ NOT DETECTED - Value from import
import { getValue } from './helpers';
processValue(getValue()); // Cross-file not tracked

Mitigation: Ensure imported values follow the same constraints. Use TypeScript for type safety.