Skip to content

plugin-e2e: Window.grafanaBootData ambient type conflicts with @grafana/data's BootData (TS2717) #2811

Description

@unlikelyzero

What happened

packages/plugin-e2e/src/index.ts declares a global ambient augmentation:

declare global {
  interface Window {
    monaco: any;
    grafanaBootData: {
      settings: {
        featureToggles: Record<string, boolean>;
        buildInfo: { version: string };
        namespace: string;
      };
    };
  }
}

Grafana core (packages/grafana-data/src/types/config.ts in grafana/grafana) declares its own,
much wider BootData type for the same window.grafanaBootData:

export interface BootData {
  user: CurrentUserDTO;
  settings: GrafanaConfig;
  navTree: NavLinkDTO[];
  assets: { light: string; dark: string };
  _femt?: boolean;
}

When a single tsc program includes both this package's shipped .d.ts and Grafana's own
ambient declaration (e.g. a Grafana core tsconfig that typechecks both app source and
@grafana/plugin-e2e), TypeScript requires merged global interface property declarations to
have the identical type (TS2717: "Subsequent property declarations must have the same type").
The two shapes are structurally incompatible (plugin-e2e's is a strict, narrower subset), so
this is normally a hard compile error.

In grafana/grafana this is currently masked only because skipLibCheck: true is inherited from
the root tsconfig, which suppresses TS2717 for declaration files. With the error suppressed,
which declaration "wins" the merge for e2e-playwright type-checking depends on unspecified
compiler file-processing order — verified empirically: reversing an include array order in
Grafana's e2e-playwright/tsconfig.json flips which declaration wins and produces 3 real type
errors in packages/grafana-runtime/src/config.ts and
packages/grafana-ui/src/components/DateTimePickers/WeekStartPicker.tsx. Grafana currently
works around this with an "order matters" comment pinning the include order — a fragile
mechanism that a TS upgrade, a skipLibCheck change, or an innocent include-list reorder could
silently flip.

Proposed fix

Type grafanaBootData as import('@grafana/data').BootData directly, so the merged property
is structurally identical to Grafana core's own declaration and TS2717 no longer applies
regardless of file order or skipLibCheck. I have this change ready locally (adds
@grafana/data as a dependencies entry of plugin-e2e, which it did not previously depend
on) and have verified it resolves the reversed-include-order regression in a local grafana/grafana
checkout. Happy to open a PR — wanted to raise the approach with maintainers first since it
changes this package's public ambient type surface and adds a new dependency.

Caveat found during verification

The fix removes the silent TS2717 landmine, but if a consumer's own @grafana/data (e.g. via
workspace source) has drifted from the @grafana/data version plugin-e2e depends on, a
different, non-silent type error can still surface (duplicate-package type structural drift,
e.g. between two versions' IconName unions) — this is normal npm/yarn dependency duplication,
not a defect in this fix, but worth being aware of for anyone who also pins @grafana/data
narrowly.

Environment

  • @grafana/plugin-e2e 3.10.0
  • Verified against grafana/grafana (branch cut from origin/main)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions