Expose more node checking / type guard API functions for developers

Suggestion

🔍 Search Terms

type guard internal api functions tsutils ts-api-utils

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

The typescript package contains many node checking / type guard API functions for developers (isAccessor, isArrayBindingPattern, etc.). Many of them are exported for public use. Some are not. Could we expose many more of them?

A bit of history: the tsutils package has existed for many years to fill in those missing type guards & other API pieces. It hasn't been maintained in a couple of years so I'm filling out a successor, ts-api-utils with a lot of help from @RebeccaStevens. We're now discussing which parts of the TypeScript API -internal and public- the package should provide.

📃 Motivating Example

Two categories of @internal functions come to mind:

• /src/compiler/factory/nodeTests.ts contains 21: isCommaToken, isExclamationToken, isQuestionToken, etc.
• See https://github.com/JoshuaKGoldberg/ts-api-utils/pull/50: there are quite a few functions within TypeScript that aren't exported but would be useful: isExpression, isExpressionNode, isUnaryExpression, etc.

💻 Use Cases

Developers writing logic to work with the TypeScript AST often want these functions as they're handy utilities. Many of them exist in tsutils for that reason.

import * as ts from "typescript";
import * as tsutils from "tsutils";

declare const node: ts.Node;

tsutils.isExpression(node);

Request: which of those internal / not-exported functions would you be open to a PR exposing to the public?

Related:

• #23719
• #50694
• #52473

Start with src/compiler/factory/nodeTests.ts and the functions referenced in ts-api-utils PR #50. Review the related issues #23719, #50694, and #52473, along with the discussion, to identify which internal or unexported guards have agreement for public exposure. Done means an agreed scope and corresponding public API changes.