Expose TokenType

[splincode]

Description

Expose isInterpolationToken together with the InterpolationToken and InterpolatedTextToken types from the public package entry point.

This lets consumers identify interpolation tokens using parser-owned semantics instead of reimplementing the token structure, for example by checking parts.length and the {{ / }} markers.

TokenType is intentionally kept internal because it is currently a const enum; the public type guard provides the runtime discriminator without exposing that implementation detail.

This is useful for prettier/prettier#20117, where Prettier needs the parser-provided interpolation boundaries when an Angular expression contains }}.

Tests

Added a public API test that verifies the exported type guard and type narrowing against tokens returned by parse().

[fisker]

splincode#12

[fisker]

Let's expose TokenType instead of a function for just InterpolationToken

[fisker]

@splincode It's out of scope for this PR, but do you know if we can parse interpolations here? I saw there is a _consumeWithInterpolation

angular-html-parser/packages/compiler/src/ml_parser/lexer.ts

Line 298 in 1701b96

this._consumeWithInterpolation(

, but I didn't have time to look into it.

[fisker]

Released https://github.com/prettier/angular-html-parser/releases/tag/v10.13.0

[splincode]

Yes. I checked it, and _consumeWithInterpolation already tokenizes the text into TEXT and INTERPOLATION tokens. _TreeBuilder._consumeText merges them back into a Text node, but preserves the original tokens in Text.tokens.

So I think we don't need another interpolation parser here. With TokenType now exposed in v10.13.0, Prettier can use token.type === TokenType.INTERPOLATION directly and rely on the interpolation boundaries produced by the lexer.

I'll update prettier/prettier#20117 to use that instead of detecting interpolation tokens from parts.