fix: remove export of OpenFeatureClient

[lukas-reining]

This PR

As discussed here #750 (comment), we should not export OpenFeatureClient from the server and web SDK. The type used outside the SDK should be Client, which is also used in the public APIs like OpenFeatureApi.

The question is, if we should mark this as breaking.
Technically it will break code that imports OpenFeatureClient instead of Client, but as @toddbaert said code using it could also be seen as "used wrong" while being technically fine.

I am still leaning towards marking it as breaking, to be sure we are not breaking something that is technically fine, just because it is unintended use. But I could also live with non-beaking.

[beeme1mr]

Perhaps we should enable the stripInternal compiler option. I haven't used it before but this may be a nice way to ensure we don't accidentally reexport it in the future.

[toddbaert]

I think we can (debatabley) consider this non-breaking, since it's an export we didn't expect people to use... it really depends how strict we want to be.

In any case, I think it might be a good idea to discuss rolling together some upcoming breaking changes. I'd like to also include:

• making it impossible to return an error resolution from providers (force them to throw if something goes wrong)
• removing setProviderAndWait and just making setProvider async

What do you guys think?

cc @lukas-reining @beeme1mr @luizgribeiro @Kavindu-Dodan

[Kavindu-Dodan]

I think we can (debatabley) consider this non-breaking, since it's an export we didn't expect people to use... it really depends how strict we want to be.

In any case, I think it might be a good idea to discuss rolling together some upcoming breaking changes. I'd like to also include:

• making it impossible to return an error resolution from providers (force them to throw if something goes wrong)
• removing setProviderAndWait and just making setProvider async

What do you guys think?

cc @lukas-reining @beeme1mr @luizgribeiro @Kavindu-Dodan

+1 for combining multiple breaking changes for the next release

[luizgribeiro]

I'd say it's a breaking change because if it's shipped as is since it would break minor upgrades in projects that are already using OpenFeatureClient.
I also think bundling more breaking changes in one new major is a good alternative.

Maybe another way that might not be a breaking change is to expose OpenFeatureClient as an alias type to Client.
I'm not a big fan of using Client as a type. Many different packages have a Client exported type and it would end up with an alias anyway.

[toddbaert]

I'd say it's a breaking change because if it's shipped as is since it would break minor upgrades in projects that are already using OpenFeatureClient. I also think bundling more breaking changes in one new major is a good alternative.

Maybe another way that might not be a breaking change is to expose OpenFeatureClient as an alias type to Client. I'm not a big fan of using Client as a type. Many different packages have a Client exported type and it would end up with an alias anyway.

I think it's OK to require people to alias things, but I would be up for changing the name to something more specific in a 2.0. I definitely don't want to alias the OpenFeatureClient though since it's a class. It's a good idea to export and reference interfaces instead of classes where-ever possible, or you can run into nasty things like this which can happen if people end up with multiple copies of a dep (we do our best to avoid that but it can happen).

[toddbaert]

I've opened this to record (small) proposed breaking changes in 2.0

[toddbaert]

@lukas-reining @luizgribeiro @beeme1mr I've rebased and resolved conflcits on this PR.

I also made the title non-breaking as we decided (though it's technically a break but not on an export we indented people to use).