Fix release - add nonshared uint8array and address api extractor fix#1360
Merged
Conversation
…e it livekit-client >=2.19 (pulled in via #1348) declares an ambient global `NonSharedUint8Array` in its own source (src/type-polyfills/non-shared-typed-arrays.d.ts) but does NOT ship that declaration in its published `dist` types. Its emitted `.d.ts` files (Track, LocalParticipant, Room, E2eeManager, ...) therefore reference a global type that downstream consumers cannot resolve. Our `tsc` build tolerates this because of `skipLibCheck: true`, but api-extractor must fully follow every rolled-up symbol and hard-fails with: ERROR: Internal Error: Unable to follow symbol for "NonSharedUint8Array" which broke the api-extractor step of `pnpm ci:publish` and blocked the release. Re-declaring the global here makes the symbol resolvable during our own type analysis. Unlike upstream -- which aliases to the non-shared `Uint8Array<ArrayBuffer>` variant for Web API compatibility in its own code -- we intentionally alias to plain `Uint8Array`: this type is only a resolution shim, and components forwards consumer-supplied `Uint8Array` values unchanged, so tightening to the non-shared variant would only break our public payload signatures for no benefit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…r pass Same root cause and fix as the core package: livekit-client >=2.19 ships `.d.ts` files that reference an ambient `NonSharedUint8Array` global it never emits, so api-extractor also crashes with "Unable to follow symbol" when it rolls up the react package's types. api-extractor builds an independent TypeScript program per package, so the shim added to @livekit/components-core is not visible here -- the react package needs its own copy in its own compilation. See the core package's polyfill for the full rationale, including why we alias to plain `Uint8Array` rather than the upstream non-shared variant. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`@microsoft/api-extractor` 7.58.8 (bumped from 7.57.6 in #1334) changed how it represents destructured object parameters. For a signature like `useChatToggle({ props }: UseChatToggleProps)` it now collapses the parameter to a synthetic `input` param but also leaves an additional phantom parameter entry whose type-token range is empty. `_writeParameterList` assumed `parameterTypeExcerpt.spannedTokens[0]` always exists and read `.kind` off it, so these phantom entries crashed markdown generation with: TypeError: Cannot read properties of undefined (reading 'kind') This broke `pnpm gen:docs` for the 8 hooks that take destructured props (useChatToggle, useTrackToggle, useFocusToggle, useMediaDevices, useMediaDeviceSelect, useParticipantTile, useStartAudio, useStartVideo) -- the next failure on the release path once the api-extractor crash above is resolved. Skip parameters with an empty type excerpt: the collapsed real parameter is emitted separately and still renders correctly, so no documentation is lost. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 0dfbcbe The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
size-limit report 📦
|
thomasyuill-livekit
approved these changes
Jul 8, 2026
The root cause is being fixed upstream in livekit/client-sdk-js#1997, which ships the `NonSharedUint8Array` declaration in livekit-client's published types. Reference that PR from both shim files and document that they are a temporary workaround: once a livekit-client release including the fix is published and this repo's `livekit-client` catalog entry is bumped to it, the type resolves from livekit-client itself and these files should be deleted. Also replaces the stale `See:` link (the upstream file is being renamed from `.d.ts` to `.ts`) with a link to the upstream PR. Comment-only change; the `type NonSharedUint8Array = Uint8Array` shim is unchanged and still required until the upstream fix ships. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
lukasIO
approved these changes
Jul 8, 2026
livekit-client 2.20.1 ships the `NonSharedUint8Array` type declaration in its published types (livekit/client-sdk-js#1997), so the local resolution shims added earlier in this branch are no longer needed. Bump the `livekit-client` catalog entry (a peerDependency of components-core/react) from `^2.18.2` to `^2.20.1` and delete both `type-polyfills/non-shared-typed-arrays.d.ts` shims; api-extractor now resolves the symbol from livekit-client itself. Removing the permissive shim (`type NonSharedUint8Array = Uint8Array`) re-exposes one genuine mismatch it was masking: `sendMessage` forwards a consumer-supplied `Uint8Array` to `localParticipant.publishData`, which livekit-client >=2.19 types as the non-shared `Uint8Array<ArrayBuffer>` variant. Cast at that internal boundary (data-channel payloads are never shared-backed) to keep this helper's public `Uint8Array` signature unchanged. Verified: `turbo run build` and `pnpm gen:docs` (api-extractor for both packages + api-documenter) pass with livekit-client 2.20.1 and no shims. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Currently the release is failing with:
There are two independent regressions on the release path, both introduced by dependency bumps since the last release was made (#1310). The api-extractor crash happens first (the reported error); fixing only it would surface the second one immediately after in gen:docs.
livekit-client >=2.19 declares an ambient global
NonSharedUint8Arrayin its source (src/type-polyfills/non-shared-typed-arrays.d.ts) but does not include that declaration in its publisheddisttypes. Its emitted .d.ts files (Track, LocalParticipant, Room, E2eeManager, ...) reference a global that consumers can't resolve.skipLibCheck: true.Fix: re-declare the ambient global in each package that runs api-extractor (coreandreact-api-extractorbuilds an independent program per package). We alias to plainUint8Arrayrather than upstream's non-sharedUint8Array<ArrayBuffer>variant: it's only a resolution shim, and the strict variant would force a breaking narrowing of our public payload signatures (Uint8Array -> Uint8Array) for no benefit. Rationale is in the file comments.This is fundamentally an upstream packaging bug -
livekit-clientshould probably include itsnon-shared-typed-arrays.d.ts. I've committed a shim to unblock this in the meantime but I think ideally it can be fixed upstream.Once
api-extractorcompletes,gen:docscrashes the vendored@livekit/api-documenterwithCannot read properties of undefined (reading 'kind'). api-extractor 7.58.8 changed how it represents destructured object params (useChatToggle({ props }: UseChatToggleProps)): it collapses them to a synthetic input param but leaves a phantom parameter entry with an empty type-token range, which_writeParameterListchokes on. This affected 8 hooks.Fix: skip parameters with an empty type excerpt — the collapsed real parameter renders separately, so no docs are lost.
Verification
turbo run build --filter=./packages/*-> ✅pnpm gen:docs(runs api-extractor for both packages + api-documenter) -> ✅ 7/7 tasks, "API Extractor completed successfully" x2skipLibCheck(the normal app setting) there are zero errors; the emitted types are as consumable aslivekit-client's own.