estree-util-is-identifier-name

A tiny estree utility that checks whether a string or code point can be a valid ECMAScript identifier name.

Library
npm
v3.0.0
3stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
23/100Needs Attention
Development Activity0
Maintenance20
Community12
Maturity60
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
64/100Good
Architecture70
Code Quality90
Innovation40
Learning Curve55

estree-util-is-identifier-name is a focused npm utility from the unified/syntax-tree ecosystem that answers one narrow but frequently-needed question: is this string, or this Unicode code point, a valid ECMAScript identifier? It wraps the ID_Start/ID_Continue Unicode property regular expressions behind a small, fully typed API, so parsers, code generators, and linters don’t have to hand-derive identifier-matching rules themselves.

The package is ESM-only, has zero runtime dependencies, and exports three pure functions — name, start, and cont — along with an optional jsx: true mode that also accepts hyphenated names like data-foo. It’s maintained by Titus Wormer (wooorm) as part of the broader unified/remark/mdx toolchain, where consistent identifier validation is needed across many downstream packages.

What You Get

  • name(value, options?) to validate a full identifier string in one call
  • start(codePoint) and cont(codePoint, options?) for building custom identifier scanners at the code-point level
  • An optional JSX mode (jsx: true) that also accepts hyphenated names such as data-foo or aria-label
  • Full TypeScript types generated from JSDoc, with no separate .d.ts file to hand-maintain
  • A zero-dependency, ESM-only package small enough to embed anywhere without bundle-size concerns

Common Use Cases

  • Validating a computed or user-supplied string before emitting it as a raw identifier in generated JavaScript
  • Implementing custom tokenizers or parsers for JS-like languages using the low-level start()/cont() code-point checks
  • Accepting JSX-style hyphenated attribute or tag names in transformers and linters via the jsx option
  • Deciding whether a dynamic property key can be written as dot-notation or must fall back to bracket notation

Under The Hood

Architecture The entire package is a single-file library: lib/index.js exports three named pure functions (start, cont, name), re-exported through a thin root index.js that also carries the Options JSDoc typedef. There is no internal layering or state — each function is a predicate built directly from five precompiled Unicode-property regular expressions (startRe, contRe, contReJsx, nameRe, nameReJsx) selected by the jsx option, making the whole “architecture” a small regex lookup table with a uniform calling convention across all three exports.

Tech Stack Pure JavaScript, ESM-only ("type": "module"), with zero runtime dependencies. Every devDependency is tooling rather than a runtime concern: TypeScript plus type-coverage check the JSDoc-typed source in strict mode, xo (an opinionated ESLint preset) and prettier enforce style, c8 measures test coverage, and remark-cli/remark-preset-wooorm lint the markdown docs — all wired together with plain npm scripts and no bundler or build step beyond emitting declaration files.

Code Quality Tests live in test.js using Node’s built-in node:test and node:assert/strict, covering ordinary identifiers, edge cases like surrogate-pair code points, empty strings, and JSX mode; the suite runs under c8 --100, which fails the build if statement or branch coverage drops below 100%. The library itself is fully typed via JSDoc comments checked in TypeScript’s --strict mode with a type-coverage gate requiring complete type coverage, and CI enforces all of this on every change. There is no meaningful error-handling surface to assess since every exported function is a pure boolean predicate.

What Makes It Unique The technique — matching Unicode ID_Start/ID_Continue properties via regex — is standard and documented in the ECMAScript spec itself, not a novel invention. Its value is as the single canonical, exhaustively tested implementation shared across the unified/syntax-tree/mdx toolchain, sparing every downstream parser or code generator from re-deriving the same regex edge cases around surrogate pairs and JSX hyphens.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search