For some of the properties above, we have defined interfaces for them already. Should we use them where possible? For example, we have an Opacity interface that could be referenced instead of duplicating it manually within RectStyle. (The same for FillStyle, StrokeStyle, Visible and StrokeDashArray.) If we aren't going to reuse those interfaces, should we delete them? Looks like Radius was already deleted in favor of defining it inside the interface.

@emmacunningham here my difficulty was the following: the StrokeStyle is specified as

export interface StrokeStyle {
  /** The stroke color in hex, rgba, hsl */
  stroke: string;
  /** The stroke width in pixel */
  strokeWidth: number;
}

but I want to to have the stroke optional and the strokeWidth required. Is there a way to achieve that? I can change the StrokeStyle type but we maybe need a different configuration in the future. Splitting the StrokeStyle into two types is useless and we can just go removing all the Stroke/Opacity interfaces.
What do you think?

I believe you can do something like this to extend StrokeStyle such that stroke becomes optional and strokeWidth remains required.

First, we need a way to keep one property as required and make the rest optional:

export type RequireOneAndMakeRestOptional<T, K extends keyof T> = { [X in Exclude<keyof T, K>]?: T[X] } & { [P in K]-?: T[P] };

and then RectBorderStyle for example could be:

export type RectBorderStyle = RequireOneAndMakeRestOptional<StrokeStyle, 'strokeWidth'> & Visible;

I'm not sure this is that much better since it requires other contributors to understand what RequireOneAndMakeRestOptional is doing to understand the type annotations where it's being used. I think that the way you have it now is more easy to follow and read.

Having the interfaces for these common styling properties I think is useful because it makes it easier for other contributors to compose new interfaces that are consistent (so we don't accidentally type stroke as a number sometimes, for example). In particulary, I think StrokeDashArray is especially useful because it is not obvious what this should be (in fact, we could probaably make this more explicit as [number, number]) for someone not familiar with the API to create a dashed stroke.

I will leave this as it is for the moment, and we can find a clear type later. You are completely right about the fact that a common styling type is required, I will like to open a PR with that in the next future #264