feat: Support zero and indefinite initialization waiting

[kinyoklion]

Gives the OpenFeature providers the initialization waiting values the OpenFeature provider spec (OFP) requires, which the numeric-only initTimeoutSeconds could not express.

• initTimeoutSeconds: 'forever' waits indefinitely for the LaunchDarkly client
• initTimeoutSeconds: 0 waits nowhere and fails initialization unless the client is already ready, so readiness is observed through provider events
• A positive timeout behaves as before, and the default is still 10 seconds
• Node provider README feature matrix row updated for the new values

Implementation details

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

OFP requirement 4.3.4 requires a value distinct from any duration to request waiting indefinitely, and 4.3.6 requires a zero wait to wait nowhere and fail initialization. Sibling changes for the same requirement: launchdarkly/openfeature-java-server#66, launchdarkly/openfeature-python-server#64, launchdarkly/openfeature-dotnet-server#71, launchdarkly/openfeature-ruby-server#36.

Describe the solution you've provided

BaseProviderConfig.initTimeoutSeconds and the Node provider's constructor parameter are now number | 'forever', and zero is no longer coalesced into the default, since ?? only replaces undefined. waitForInitialization treats a falsy timeout as no timeout, so zero cannot be passed through: initialization races the pending initialization promise against an immediately rejected one, which succeeds only when the client is already ready.

The Cloudflare provider is unaffected because it evaluates from a KV namespace and has no data source to wait for.

Describe alternatives you've considered

number | null was used initially for the indefinite case; 'forever' reads better at the call site and matches the repository's preference for string unions. Adding initialized() to the client contract would let the zero case be checked directly, but that is a breaking change to a published interface for behavior the existing promise already expresses.

Additional context

Verified with yarn workspace @launchdarkly/openfeature-js-server-common test (82 tests), yarn workspace @launchdarkly/openfeature-node-server test (29 tests), and lint, format and build checks for both packages.

Link to Devin session: https://app.devin.ai/sessions/1fd3fcbfe79f482e8b58be29e8df2ffb
Open in Devin Desktop: https://app.devin.ai/desktop/session/1fd3fcbfe79f482e8b58be29e8df2ffb?variant=devin
Requested by: @kinyoklion

---

Note

Overview
Extends initTimeoutSeconds on the shared BaseOpenFeatureProvider and the Node LaunchDarklyProvider to number | 'forever', aligning initialization with the OpenFeature provider spec.

'forever' calls waitForInitialization() with no timeout. 0 no longer falls through to the 10-second default (only undefined does); initialization races the client’s init promise against an immediate failure so it succeeds only when the client is already ready, otherwise it throws a clear error. Positive timeouts behave as before (default 10 seconds).

The Node provider README initialization row documents the new values, and unit tests cover indefinite wait, zero-timeout failure, and zero-timeout success when already ready.

^{Reviewed by Cursor Bugbot for commit 87e9a23. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[github-actions]

@launchdarkly/js-client-sdk size report
This is the brotli compressed size of the ESM build.
Compressed size: 32642 bytes
Compressed size limit: 34000
Uncompressed size: 117007 bytes

[github-actions]

@launchdarkly/js-sdk-common size report
This is the brotli compressed size of the ESM build.
Compressed size: 29338 bytes
Compressed size limit: 29500
Uncompressed size: 141229 bytes

[github-actions]

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