Skip to content

[eas-cli] Accept navigation metric aliases as positional args to observe:metrics#3973

Open
douglowder wants to merge 2 commits into
mainfrom
doug/eng-23109-eas-cli-include-navigation-metric-names-in-observemetrics
Open

[eas-cli] Accept navigation metric aliases as positional args to observe:metrics#3973
douglowder wants to merge 2 commits into
mainfrom
doug/eng-23109-eas-cli-include-navigation-metric-names-in-observemetrics

Conversation

@douglowder

@douglowder douglowder commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

Why

When running observe:metrics in non-interactive mode, navigation metric names could not be passed into the command; only app startup metrics were accepted.

How

  • Included the navigation metrics in the validation check
  • Renamed the short names (keys) for the navigation metrics to avoid confusion with app startup metric short names

Test Plan

  • Tested locally
  • Unit tests added and updated

@linear-code

linear-code Bot commented Jul 6, 2026

Copy link
Copy Markdown

ENG-23109

Copy link
Copy Markdown
Contributor Author

This stack of pull requests is managed by Graphite. Learn more about stacking.

@douglowder douglowder requested review from Ubax, jonsamp and tsapeta and removed request for tsapeta July 6, 2026 21:42
@douglowder douglowder marked this pull request as ready for review July 6, 2026 21:43
@codecov

codecov Bot commented Jul 6, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.33%. Comparing base (bc63692) to head (a109535).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3973      +/-   ##
==========================================
+ Coverage   59.33%   59.33%   +0.01%     
==========================================
  Files         936      936              
  Lines       41172    41177       +5     
  Branches     8671     8675       +4     
==========================================
+ Hits        24424    24429       +5     
  Misses      16654    16654              
  Partials       94       94              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

douglowder and others added 2 commits July 6, 2026 18:33
…rve:metrics

The observe:metrics command listed navigation metrics in the interactive
metric picker (via METRIC_SHORT_NAMES) but its positional-arg validator
was restricted to Object.keys(METRIC_ALIASES), so
`eas observe:metrics nav_tti` and the other nav aliases were rejected
by oclif before the resolver ever saw them.

Widen the arg's `options` to include NAVIGATION_METRIC_ALIASES, extend
resolveMetricName to resolve navigation short aliases (cold_ttr,
warm_ttr, nav_tti) to their expo.navigation.* full names, and include
both alias sets in the non-interactive-mode "available metrics" error
message. resolveNavigationMetricName remains for observe:routes, which
should not accept app-startup metric names.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@douglowder douglowder force-pushed the doug/eng-23109-eas-cli-include-navigation-metric-names-in-observemetrics branch from 6c61818 to a109535 Compare July 7, 2026 01:34
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

✅ Thank you for adding the changelog entry!

Comment on lines 3 to 16
export const METRIC_ALIASES: Record<string, string> = {
tti: 'expo.app_startup.tti',
ttr: 'expo.app_startup.ttr',
cold_launch: 'expo.app_startup.cold_launch_time',
warm_launch: 'expo.app_startup.warm_launch_time',
bundle_load: 'expo.app_startup.bundle_load_time',
update_download: 'expo.updates.download_time',
};

export const NAVIGATION_METRIC_ALIASES: Record<string, string> = {
cold_ttr: 'expo.navigation.cold_ttr',
warm_ttr: 'expo.navigation.warm_ttr',
nav_cold_ttr: 'expo.navigation.cold_ttr',
nav_warm_ttr: 'expo.navigation.warm_ttr',
nav_tti: 'expo.navigation.tti',
};

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we combine them into single METRIC_ALIASES?

Something like:

export const METRIC_ALIASES: Record<string, string> = {
  ...NAVIGATION_METRIC_ALIASES,
  tti: 'expo.app_startup.tti',
  ttr: 'expo.app_startup.ttr',
  cold_launch: 'expo.app_startup.cold_launch_time',
  warm_launch: 'expo.app_startup.warm_launch_time',
  bundle_load: 'expo.app_startup.bundle_load_time',
  update_download: 'expo.updates.download_time',
}

Then you could remove

if (NAVIGATION_METRIC_ALIASES[input]) {
  return NAVIGATION_METRIC_ALIASES[input];
}

and

KNOWN_FULL_NAVIGATION_NAMES.has(input) ||

Comment on lines +60 to +61
expect(() => resolveMetricName('bogus')).toThrow(/nav_tti/);
expect(() => resolveMetricName('bogus')).toThrow(/cold_launch/);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you modify this tests to be a bit more accurate?

Maybe even something like:

expect(() => resolveMetricName('bogus')).toMatchSnapshot();

This would make it easy to update, yet verify that all the metrics are there

description: 'Metric to query (e.g. tti, cold_launch, nav_tti)',
required: false,
options: Object.keys(METRIC_ALIASES),
options: [...Object.keys(METRIC_ALIASES), ...Object.keys(NAVIGATION_METRIC_ALIASES)],

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be reverted if the metrics are spread in METRIC_ALIASES

Comment on lines +13 to +14
nav_cold_ttr: 'expo.navigation.cold_ttr',
nav_warm_ttr: 'expo.navigation.warm_ttr',

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we display a warning if someone uses the old aliases? I'm not sure if we advertised this as stable or unstable (we can just remove the alias without a breaking change)

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