feat: Add public analytics-metadata entry point - #243
Open
saipavan-narasaraj wants to merge 1 commit into
Open
Conversation
Exposes the analytics metadata API through the public @cloudscape-design/component-toolkit/analytics-metadata and .../analytics-metadata/utils paths. Both are thin re-exports of the existing internal/analytics-metadata modules, so the activation flag stays a single module-level singleton shared with existing internal consumers. The internal paths remain unchanged and are not deprecated.
saipavan-narasaraj
requested review from
pan-kot
and removed request for
a team
August 5, 2026 22:34
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
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
Adds a public
@cloudscape-design/component-toolkit/analytics-metadataentrypoint (and
.../analytics-metadata/utils) exposing the analytics metadata APIthat today is only reachable via
internal/analytics-metadata.Component libraries built on top of Cloudscape instrument their own components
with this mechanism, alongside the metadata Cloudscape components emit, so that
one extraction returns a single consistent hierarchy. Because the entry points
live under
internal/with no stability commitment, such a library has toredefine the types in a wrapper package to avoid leaking an internal path into
its own public API, and re-verify the surface on every toolkit release. With a
public path those redefinitions become plain re-exports.
The functions are already published in the package's
exportsmap, so this iscloser to documenting existing surface than adding new API.
Changes
src/analytics-metadata/index.tsre-exportingactivateAnalyticsMetadata,getAnalyticsMetadataAttributeand the typesGeneratedAnalyticsMetadata,GeneratedAnalyticsMetadataFragment,LabelIdentifier.src/analytics-metadata/utils.tsre-exportinggetGeneratedAnalyticsMetadata,getComponentsTreeand the typesGetComponentsTreeOptions,OptionItem,TabItem.exportsandtypesVersionsentries for both paths.entry point, and shared activation state.
Kept as two paths rather than one so component-runtime consumers of
getAnalyticsMetadataAttributedo not pull in the page-scanner andlabel-extraction code.
Non-goals
internal/analytics-metadataand.../utilsare unchanged and not deprecated.copy would silently split it; re-exporting keeps one instance.
Testing
npm run build— verifiedlib/analytics-metadata/{index,utils}.{js,d.ts}andlib/mjs/analytics-metadata/{index,utils}.{js,d.ts}are all emittednpm run lint— cleanCI=true npm run test:unit— 52 suites / 491 tests passlib/, both formats:require('./analytics-metadata/index.js')andimport('./mjs/analytics-metadata/utils.js')export the expected namesgit secrets --scanon the changed filesBy submitting this pull request, I confirm that you can use, modify, copy, and
redistribute this contribution, under the terms of your choice.