Skip to content

Add linting for RRI URL construction - #5847

Draft
backspace wants to merge 2 commits into
mainfrom
cs-12484-no-url-on-identifier-lint
Draft

Add linting for RRI URL construction#5847
backspace wants to merge 2 commits into
mainfrom
cs-12484-no-url-on-identifier-lint

Conversation

@backspace

Copy link
Copy Markdown
Contributor

If this can’t work in host though it might not be worth it.

backspace and others added 2 commits August 21, 2026 08:57
`RealmIdentifier` and `RealmResourceIdentifier` are branded strings, so
`new URL(identifier)` typechecks and throws only at runtime, and only for the
canonical form. Nothing in the repo can currently see that: the compiler is
structurally blind to it, and no package lints with type information, so a
type-aware ESLint rule has nowhere to run yet.

This asks the question directly through the TypeScript API instead — walking a
program's types for `new URL(x)` where x's type carries either brand — so the
inventory is available without changing how anything is linted.

Reports 19 sites across runtime-common, base and host. Two caveats for whoever
triages them: roughly half are test fixtures passing a branded constant that
happens to be URL-shaped, and `.gts` files are invisible here because a raw
TypeScript program cannot parse them, so host component coverage is partial.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The realm-identifier types are branded strings, so `new URL(identifier)`
typechecks and throws only at runtime, and only for the canonical prefix form.
The compiler is structurally unable to flag it, which is why the same defect has
recurred: two sites fixed in May were broken again by August, and a one-step
canonicalization later failed every host shard on it.

The brand is a type, so a rule with type information can see what the compiler
permits. This asks whether an argument's type carries either brand, walking
intersections and unions, and points at the alternatives rather than only
refusing.

Reads parser services directly rather than taking a dependency on
`@typescript-eslint/utils`, and returns no visitors when type information is
absent — so the rule is inert rather than wrong wherever a config has no
`parserOptions.project`, and can be adopted per package.

Turned on for runtime-common, the first package here to lint with type
information. It reports six existing sites as warnings; they need triage into
genuine network boundaries and parses that should never have happened, and the
rule goes to error once that list is empty. Type information costs this
package's lint roughly five seconds (4s to 9s), which is why the scope is one
package rather than the repo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

Host Test Results

    1 files      1 suites   2h 8m 1s ⏱️
4 368 tests 4 354 ✅ 14 💤 0 ❌
4 387 runs  4 373 ✅ 14 💤 0 ❌

Results for commit ad20e98.

Realm Server Test Results

    1 files      1 suites   16m 15s ⏱️
2 206 tests 2 206 ✅ 0 💤 0 ❌
2 289 runs  2 289 ✅ 0 💤 0 ❌

Results for commit ad20e98.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant