As we are now actively using TypeScript we accumulate various useful helper utilities, like UnwrapPromise
. As I understand we have at least 3 "UnwrapPromise
" helpers in our codebase. What shall we do about TypeScript utilities?
utility-types
.type-fest
./src/types
or /src/core
.UnwrapPromise
, Omit
, Brand
, etc.@kbn/types
(or @kbn/utility-types
) in /packages
folder.I would install utility-types
.
I'm ++ to options 1 and/or 3. I think there's certainly benefit to having these utility types centralized, but I don't know utility-types
well enough yet to know if it covers all of our use-cases. We might end up doing a bit of both.
Yeah, I'm a fan of a shared set of utility types that might just re-export types from utility-types
and might be custom implementations. But I'd ask that it's a package so I can easily use it from other packages. Happy to set this up if the package bit is a deal breaker.
@spalger I added option 5.
in OP, are you proposing basically that?
a shared set of utility types that might just re-export types from
utility-types
and might be custom implementations
++ this feels like the most flexible option, otherwise we might end up creating our own shared set of utility types later anyway if we need something that lib doesn't offer.
馃憤 for 5 to have benefits of 1 & 3.
(5) sounds great 馃挴
I vote 5锔忊儯 with a set of sensible defaults like utility-types
(whether or not coming from that library or copied over, I don't mind :D)
Looks like there is a general consensus if favor of option 5. Can we move forward and resurrect (for a slightly different purpose) @kbn/types then? :slightly_smiling_face:
@azasypkin I would call it @kbn/utility-types
because
utility-types
package@kbn/types
for Kibana types.
- To make it clear that those are utility types
- So, we can have the option to use @kbn/types for Kibana types.
Sure.
- It will re-export utility-types package
It shouldn't matter which package we use under the hood, we can easily switch to another one in the future or write our own utility types from scratch and the name of our own package shouldn't depend on that.
Most helpful comment
Yeah, I'm a fan of a shared set of utility types that might just re-export types from
utility-types
and might be custom implementations. But I'd ask that it's a package so I can easily use it from other packages. Happy to set this up if the package bit is a deal breaker.