Skip to content

Strip the view identity members from the published declarations - #6206

Closed
candrewlee14 wants to merge 5 commits into
drizzle-team:rc5from
candrewlee14:strip-view-symbol-keys
Closed

Strip the view identity members from the published declarations#6206
candrewlee14 wants to merge 5 commits into
drizzle-team:rc5from
candrewlee14:strip-view-symbol-keys

Conversation

@candrewlee14

@candrewlee14 candrewlee14 commented Aug 29, 2026

Copy link
Copy Markdown

Stacked on #6200, #6201, #6202 and #6203. Review only the last commit.

What

The view classes leak two kinds of nominal member into the emitted .d.ts.

Symbol.for-keyed config properties[PgViewConfig], [MySqlViewConfig], and the materialized / other-dialect equivalents. A Symbol.for key is a distinct computed key per declaration site, so copy A's PgView carries a property copy B's does not, and vice versa — even though Symbol.for guarantees the underlying runtime symbol is shared across copies. The type contradicts the runtime.

This is already handled correctly elsewhere: every Symbol.for key Table declares ([TableName], [Columns], …) is @internal and therefore stripped, which is exactly why the table and column types were portable while the views were not. This applies the same treatment.

Protected brand members$MySqlViewBrand and friends, which exist only to keep the view classes distinct at type level and are never callable.

Result

PgView, MySqlView and SQLiteView flip to portable. 12 lines.

Note

I originally had this bundled into a larger sweep. It is separated because it stands on its own: it is small, follows an existing in-repo precedent, and is worth landing whether or not the broader sweep is wanted.

cursoragent and others added 5 commits August 29, 2026 11:44
Strip implementation-only query-builder details from published declarations, infer decoder results structurally, and compile two physical package copies to prevent regressions.
The single SQL assignment only guarded one type. Replace it with a table of
public types probed in one tsc program, asserting both directions: a portable
type regressing fails, and a known leak becoming portable fails too, prompting
the flag to be flipped.

Records the measured state of the surface, annotating each known leak with the
private/protected member responsible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qd99Mmmi1fZkKQiV3u1jXy
Name#brand, Param#brand and CodecsCollection#resolveTypes are implementation
details that reached the emitted .d.ts as protected members, making all three
types nominal and so non-portable between two installs of the package.

resolveTypes is declared as a field rather than left as a constructor parameter
property: on a parameter the @internal marker survives into the emitted
constructor signature as a stray comment.

Flips Param, Name and CodecsCollection to portable in the matrix. The three
dialects do not follow -- with the nominal blocker gone they fail structurally
instead, on the anonymous recursive BuildRelationalQueryResult['selection'],
which is recorded as their blocker.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qd99Mmmi1fZkKQiV3u1jXy
PgColumn#toBuilder returns a PgColumnBuilder, so the builder's private and
protected members are part of PgColumn's published shape, and PgTable's
_.columns index signature carries them up to the table. One private field was
therefore enough to make every pg table and column type non-portable between
two installs.

config follows its base: ColumnBuilder#config is already @internal and the pg
override had not inherited the marker.

The other dialects declare the same foreignKeyConfigs field but are unaffected,
since only pg-core exposes toBuilder() in a public return type.

Flips PgTable and PgColumn to portable. NodePgDatabase stays recorded as a known
leak: its chain runs through the session, transaction and relational query
builder classes and does not converge to a contained change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qd99Mmmi1fZkKQiV3u1jXy
The view classes leaked two kinds of nominal member into the emitted .d.ts:

Symbol.for-keyed config properties ([PgViewConfig], [MySqlViewConfig] and the
materialized/dialect equivalents). A Symbol.for key is a distinct computed key
per declaration site, so copy A's PgView carries a property copy B's does not,
even though Symbol.for guarantees the runtime symbol is shared. Table already
marks every Symbol.for key it declares @internal, which is why the table and
column types were portable while the views were not; this applies the same
treatment.

Protected brand members ($MySqlViewBrand and friends), which exist only to keep
the view classes distinct at type level.

Flips PgView, MySqlView and SQLiteView to portable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qd99Mmmi1fZkKQiV3u1jXy
@candrewlee14

Copy link
Copy Markdown
Author

Consolidated into #6200. The whole change is 244 lines across 16 files, and because a fork PR cannot base itself on another fork branch, every PR in the stack was already showing all of its ancestors' commits — so the split bought no review isolation, just six merges and five rebases. It is now one PR with these commits intact, plus #6205 for the single change that touches observable API.

@candrewlee14
candrewlee14 deleted the strip-view-symbol-keys branch August 29, 2026 19:02
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.

2 participants