Feature/custom types

[akinorimizushima]

About the changes

This change ensures that only specific feature names can be used with isEnabled, catching typos at compile time.

import { initialize } from 'unleash-client';

declare module 'unleash-client' {
  interface CustomTypeOptions {
    name: 'aaa' | 'bbb';
  }
}

const client = initialize({});

client.isEnabled('aaa');
client.isEnabled('bbb');
client.isEnabled('ccc'); // Error

[kwasniew]

would type GetCustom<K extends PropertyKey, Fallback> = K extends keyof CustomTypeOptions ? CustomTypeOptions[K] : Fallback; achieve the same?

[akinorimizushima]

Yes, that should be the same. Updated.

[coveralls]

Pull Request Test Coverage Report for Build 18814047319

Details

• 2 of 2 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 89.931%

---

Totals
Change from base Build 18010500472:	0.0%
Covered Lines:	1267
Relevant Lines:	1348

---

💛 - Coveralls

[kwasniew]

If we decide to make type safe variant names or add extra type safety to other parts of the feature flag domain this interface name may be limiting. My understanding is that this name is inspired by some other libraries doing interface merging for user enhanced type safety. What are the pros and cons of calling the interface FeatureFlagNames or something more specific and intention revealing?

[akinorimizushima]

This is inspired by i18next's user custom type. https://www.i18next.com/overview/typescript#create-a-declaration-file. I took the same interface name so we could add any other custom user types to the interface in the future. But actually I don't have strong opinions on it. So I will leave it to you.

[kwasniew]

what about? UnleashTypes { flagNames: 'aaa' | 'bbb'} It will make it obvious from the interface name what you're changing and the property will be explicit that we're affecting flag names

[kwasniew]

Overall a great change. Thanks for your contribution. Before we merge it I'd like to decide on the exported interface name since it will be part of the public contract.

[chriswk]

If I was looking at this type declaration, I'm not sure I'd understand what we wanted to use CustomTypeOptions for. Though this reminds of what we have in the rust-sdk, personally I'd prefer if the type was ValidFeatureNames or something similar.