refactor: update LDClient to use LDContextPartial for identify methods

[joker23]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

sdk-1709

Describe the solution you've provided

• Changed the identify and identifyResult methods in LDClient to accept LDContextWithAnonymous instead of LDContext, allowing for more flexible context handling.
• Introduced LDContextWithAnonymous type in a new LDContext.ts file to define contexts that may not have a key.
• Updated documentation around the anonymous context type to explain that client side sdks will assign a key to a context that does not have one.
• Updated browser SDK to use new context type for identification functions
• updated unit tests to ensure that anonymous contexts with undefined keys can be processed

Provide a clear and concise description of what you expect to happen.

Additional context

This change is prompted by seeing the type inconsistencies between v3 and v4 browser sdk. Since we have an ensureKey function that will fedrate a context id to the context if it does not have one, then we should also be able to support passing in contexts that do not have keys.

---

Note

Aligns identify APIs to accept contexts without pre-generated keys and centralizes typing for anonymous contexts.

• Adds LDContextWithAnonymous type in shared/sdk-client/src/api/LDContext and re-exports from package entry points
• Updates identify/identifyResult signatures in LDClient, LDClientImpl, BrowserClient, and createClient to use LDContextWithAnonymous
• Updates ensureKey to accept LDContextWithAnonymous and generate keys for anonymous single/multi-kind contexts
• Adjusts browser/tests to pass anonymous contexts without empty key and updates related imports
• Minor doc/type export tweaks in common.ts, index.ts, and API surfaces

^{Written by Cursor Bugbot for commit 10d285d. This will update automatically on new commits. Configure here.}

[github-actions]

@launchdarkly/browser size report
This is the brotli compressed size of the ESM build.
Compressed size: 171262 bytes
Compressed size limit: 200000
Uncompressed size: 798483 bytes

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 25394 bytes
Compressed size limit: 26000
Uncompressed size: 124693 bytes

[github-actions]

@launchdarkly/js-client-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 19359 bytes
Compressed size limit: 20000
Uncompressed size: 99863 bytes

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 23334 bytes
Compressed size limit: 25000
Uncompressed size: 81374 bytes

[kinyoklion]

I think this typing looks good for a multi-kind context, but not for a single kind context. In that this typing for a single kind would make key appear to be not an available option.

I wonder if we should just be using basically a copy of the single/multi context kinds with key correct specified as being optional. Then converting that for internal use?

Though, I suppose, it could be an Omit and then & { key?: string }. I want to make sure we have somewhat intelligible code completion though.

[kinyoklion]

Or it could be type singleKindOptionalKey = Omit<LDSingleKindContextBase, 'key'> | LDSingleKindContextBase

Though again I am not sure how good the intellisense for that would be. Maybe fine.

[joker23]

I think there is something fundamentally wrong here... so the ensureKey function will ONLY federate the context with a key if the context is anonymous:

js-core/packages/shared/sdk-client/src/context/ensureKey.ts

Line 33 in 13ce456

if (anonymous && !key) {

So given that perhaps the correct thing to do is create an anonymous context interface, eg:

interface anonymousSingleKindContext extends Omit<LDSingleKindContextBase, 'key'> {
  key?: string;
  anonymous: boolean;
}

And do the same for multi of course

Then ultimately the LDContext that could be used in a client side identify will be:

type LDContextWithAnonymous =
  | LDSingleKindContext                         // original single kind context
  | anonymousSingleKindContext          // anon context that could be missing key
  | multiKindContextWithAnonymous;

@kinyoklion FYI

[kinyoklion]

This seems like the right path.

We do need to also consider what the impact of this will be consumption side. My reflex is that it should be exported as LDContext, but if not, then we need to make sure that LDContext doesn't upset the structural typing.

[joker23]

Ended up going the route of introducing a new type since I think there is still some value in having a context type that can match a context that is "ensured". Typescript is a bit finicky.