Add types for cds.utils.colors

[swaldmann]

Requires cap-js/docs#1285 for the @see link to work.

See cap/cds/pull/4656

[daogrady]

Thanks for this contribution! Seeing that the colour strings seem to be used as both primary and background-colour, would pulling them out into a separate type be desirable?

Alternatively just as a dictionary.

[chgeo]

Since which sap/cds version is this available? Should document this.
@daogrady do we have a @since tag or so?

[daogrady]

@since is valid in JSDoc, yes. Possibly not in TSDoc, but I don't see why we should not use it anyway.

[swaldmann]

Since which sap/cds version is this available?

Was merged just a week ago, so >= 8.3.0.

should document this

Yep :) cap-js/docs#1285

seeing that the colour strings seem to be used as both primary and background-colour, would pulling them out into a separate type be desirable?

Two reasons why I kept it separate:

• There are some small exceptions, e.g. GRAY is available as a foreground color, but not as a background color
• While the key names are the same the constant values of RED ('\x1b[31m') and bg.RED ('\x1b[41m') are different
  → sharing a type/dict seems to imply a reuse that's semantically not there

[daogrady]

There are some small exceptions, e.g. GRAY is available as a foreground color, but not as a background color

I see, then maybe

type Colors = {
  BLUE: string,
  GREEN: string,
  ...
}

type colors: Colors & {
  ITALIC: string,
  ...
  GRAY: string,  // exclusive to foreground colors
  bg: Colors & {
      DEFAULT: string
  }
}

?

[swaldmann]

I just found out I could type the values more explicitly using <constant escape sequence> | '', as those are the only values they can take on. This is a tighter typing (which is good!) but it doesn't allow us to reuse the values from a type/dict.

[daogrady]

That looks indeed better. Still not super stoked about this looming typo-catastrophe, but I'm probably blowing this out of proportion. 🙂