feat: implement waitForInitialization for browser sdk 4.x

[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

• feat: adding waitForInitialize to browser 4.x
• test: adding unit tests for waitForInitilization

Describe the solution you've provided

Added waitForInitialization function to browser 4.x implementation.

Additional context

• I kept the method signiture the same as 3.x but am open to updating it to align with what we have in the server sdks f({timeout: 5}) instead of f(5)
• I "simplified" the way we are tracking for the initialization state to a boolean. It looks like our new identification would not be throwing which minimizes the reject conditions... I can add those back in case we get an error status returned? At that point we might want to just wait for the timeout to throw.
• I put in a default 5 seconds timeout on the wait
• I also added in an initialized event that a successful identify will emit, I figured that would be a way for developers to know if LDClient initialized even if the initialization goes past timeout.

---

Note

Adds browser waitForInitialization with timeout handling and an initialized event, plus tests and supporting types.

• Browser SDK (client):
  • Add waitForInitialization(options) returning LDWaitForInitializationResult (complete | timeout | failed), implemented with a cancelable timeout and internal init state tracking.
  • Resolve initialization on successful identifyResult; expose waitForInitialization on the PIMPL client.
  • Define new types/interfaces in src/LDClient.ts for wait results/options.
• Events/Core:
  • Emit "initialized" on successful identify (LDClientImpl), and add "initialized" to LDEmitter event names.
• Compat API:
  • Exclude waitForInitialization from compat/LDClientCompat interface.
• Tests:
  • Add tests validating waitForInitialization blocks until ready and resolves with timeout when initialization exceeds the timeout.

^{Written by Cursor Bugbot for commit ed10b6f. 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: 169118 bytes
Compressed size limit: 200000
Uncompressed size: 789399 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 size report
This is the brotli compressed size of the ESM build.
Compressed size: 22390 bytes
Compressed size limit: 25000
Uncompressed size: 77125 bytes

[github-actions]

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

[cursor]

Bug: Initialization failure returns timeout instead of failed status

The identifyResult method only calls _initResolve when res.status === 'completed'. If identify fails with 'error', 'timeout', or 'shed' status, _initResolve is never called. This means waitForInitialization will always return { status: 'timeout' } for failed identifications, even though LDWaitForInitializationFailed type with status: 'failed' exists. Users cannot distinguish between an actual timeout and a genuine initialization failure.

 

[joker23]

I think this is fine... if there is an error on one of the identifies then we will timeout here. Identification errors can be handled in the identify().catch() in case developers would want to try something else on error that could ultimately yield a successful identify within the waitForInitialization timeout.