GeezerVison

nit: could we just add test-types as a second step in the typecheck job above? Is there a reason you want a second runner?

Just to make it obvious what the failure is.

nit:

Good call. I missed this during a name change.

This type contains 6 hand-crafted keys (xaxis.range[0], etc.) but LayoutUpdate doesn't type these keys at all.
This starts to look like 2 sources of truth for these types. And already, the two definitions are drifting:
the hand-crafted keys here define values that are narrower than in LayoutUpdate. xaxis.range[0]?: number misses date axes with values like 2026-10-16.

What do you think about moving the hand-typed keys here into LayoutUpdate with the type widened to include date strings? That way there would be a single definition.

These actually should have been deleted. LayoutUpdate should handle any of the attribute paths, so we don't need to specify individual ones here.

The overloads you add here are good, but can still report "errors" on perfectly valid code.

Example:

import * as Plotly from 'plotly.js';
type RelayoutArg = Parameters<typeof Plotly.relayout>[1];
const wrapped: RelayoutArg = { autosize: true };

There is a red squiggle as typescript evaluates against the "last" overload and completely misses the other valid overload.
Typescript says to put the most generic signature last. What do you think about including a generic "catch-all" overload at the end for these kinds of cases?

export function relayout(root: Root, astr: string | LayoutUpdate, val?: any): Promise<PlotlyHTMLElement>;

The same comment applies to the restyle overloads.

Good idea!