Skip to content

fix(types): export MetricObjectWithValues, MetricValue and related types#786

Open
milcho0604 wants to merge 2 commits into
prometheus:mainfrom
milcho0604:fix/export-metric-object-types
Open

fix(types): export MetricObjectWithValues, MetricValue and related types#786
milcho0604 wants to merge 2 commits into
prometheus:mainfrom
milcho0604:fix/export-metric-object-types

Conversation

@milcho0604

Copy link
Copy Markdown

Registry.getMetricsAsJSON() returns MetricObjectWithValues<MetricValue<string>>[], and the per-metric get() methods return MetricObjectWithValues<...>, but those types — along with the base MetricObject and MetricValueWithName — are not exported from index.d.ts.

As a result, consumers cannot name the return type of these public methods and have to fall back to workarounds like Awaited<ReturnType<Registry['getMetricsAsJSON']>>.

This exports the four types, consistent with the ~20 other public types already exported from the same declaration file. No behavior change, declaration-only.

  • npm run compile-typescript passes.
  • prettier --check index.d.ts passes.
  • Verified a consumer can now import { MetricObjectWithValues, MetricValue } from 'prom-client' and annotate the getMetricsAsJSON() result.

`Registry.getMetricsAsJSON()` returns
`MetricObjectWithValues<MetricValue<string>>[]`, and the per-metric
`get()` methods return `MetricObjectWithValues<...>`, but those types
(along with the base `MetricObject` and `MetricValueWithName`) were not
exported. Consumers could not name the return type without resorting to
`Awaited<ReturnType<...>>` workarounds. Export them, consistent with the
~20 other public types already exported from this declaration file.

Signed-off-by: Changhyun Kim <milcho0604@gmail.com>
@milcho0604
milcho0604 force-pushed the fix/export-metric-object-types branch from f0d810c to bc92c0d Compare July 21, 2026 08:58
@jdmarshall

Copy link
Copy Markdown
Contributor

I think some TS unit tests would be great here.

Signed-off-by: Changhyun Kim <milcho0604@gmail.com>
@milcho0604

Copy link
Copy Markdown
Author

Thanks for taking a look, and good call on wanting test coverage.

One honest caveat I ran into while adding it: because TypeScript resolves top-level types in type position even without the export keyword, a compile-only test can't actually assert the export itself — removing export from these types still type-checks. So I couldn't write a test that fails purely on the export being dropped.

What I did add to test/typescript.ts is a usage example that names the return types of getMetricsAsJSON(), getMetricsAsArray(), and Metric#get() via the now-exported type names. It exercises the intended public surface and will catch the types being removed, renamed, or reshaped, and it's compiled by tsc --project . in CI.

For context, the real value of the explicit export here is discoverability rather than a compile fix: exported symbols are what IDE auto-import suggests and what API-doc tooling (typedoc/api-extractor) surfaces, so consumers can import { MetricObjectWithValues } intentionally instead of relying on TS's non-exported-type leniency. Happy to adjust the test if you'd prefer a different shape.

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