Skip to content

feat: Add public analytics-metadata entry point - #243

Open
saipavan-narasaraj wants to merge 1 commit into
cloudscape-design:mainfrom
saipavan-narasaraj:feat/public-analytics-metadata-entry-point
Open

feat: Add public analytics-metadata entry point#243
saipavan-narasaraj wants to merge 1 commit into
cloudscape-design:mainfrom
saipavan-narasaraj:feat/public-analytics-metadata-entry-point

Conversation

@saipavan-narasaraj

Copy link
Copy Markdown

Summary

Adds a public @cloudscape-design/component-toolkit/analytics-metadata entry
point (and .../analytics-metadata/utils) exposing the analytics metadata API
that 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 to
redefine 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 exports map, so this is
closer to documenting existing surface than adding new API.

Changes

  • New src/analytics-metadata/index.ts re-exporting activateAnalyticsMetadata,
    getAnalyticsMetadataAttribute and the types GeneratedAnalyticsMetadata,
    GeneratedAnalyticsMetadataFragment, LabelIdentifier.
  • New src/analytics-metadata/utils.ts re-exporting getGeneratedAnalyticsMetadata,
    getComponentsTree and the types GetComponentsTreeOptions, OptionItem, TabItem.
  • exports and typesVersions entries for both paths.
  • Unit test asserting the public surface, function identity with the internal
    entry point, and shared activation state.

Kept as two paths rather than one so component-runtime consumers of
getAnalyticsMetadataAttribute do not pull in the page-scanner and
label-extraction code.

Non-goals

  • No behaviour changes. Both files are pure re-exports.
  • internal/analytics-metadata and .../utils are unchanged and not deprecated.
  • No new implementation. The activation flag is module-level state, so a second
    copy would silently split it; re-exporting keeps one instance.
  • No version bump or changelog (none exists in this repo).

Testing

  • npm run build — verified lib/analytics-metadata/{index,utils}.{js,d.ts} and
    lib/mjs/analytics-metadata/{index,utils}.{js,d.ts} are all emitted
  • npm run lint — clean
  • CI=true npm run test:unit — 52 suites / 491 tests pass
  • Runtime resolution from lib/, both formats:
    require('./analytics-metadata/index.js') and
    import('./mjs/analytics-metadata/utils.js') export the expected names
  • git secrets --scan on the changed files
  • Integ tests not run locally (need Chrome + chromedriver); relying on CI

By submitting this pull request, I confirm that you can use, modify, copy, and
redistribute this contribution, under the terms of your choice.

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
saipavan-narasaraj requested a review from a team as a code owner August 5, 2026 22:34
@saipavan-narasaraj
saipavan-narasaraj requested review from pan-kot and removed request for a team August 5, 2026 22:34
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