Align evaluation behavior for string based operators

We are aligning the behavior for all string based operators in this release so that we try to convert accidentally provided incorrect types to strings and evaluate instead of returning false by default.

New operators and improvements

• Added support for "string contains none" operator.
• Improved the logic to update evaluation rule sets so that it's less likely the rule sets stay stale for any extended period of time.
• Moved exposure logging for "fetch from server" fallback case from SDK to statsig server

v4.4.0 - adding support for private user attributes

We are adding support for private user attributes with this release. privateAttributes can be set on StatsigUser and any info set in it will only be used for evaluation/targeting purposes, and removed from any logs sent to Statsig server. See more info at https://docs.statsig.com/server/nodejsServerSDK#private-attributes

Improvements to certain condition evaluations

• swapped out the user agent parser to a different one so that all of Statsig's server SDKs are using the same core regex to parse UA strings and will get the same results.
• added support for string case sensitive comparisons

Introduction of Experiment+

v4.1.0 made some final adjustments to how we evaluate conditions in order to support Experiment+. Read more about Experiment+.

New major release with breaking API changes

With v4.0.1 we are introducing a few breaking changes on our APIs, along with other optimizations and bug fixes.

1. Making user and user.userID required for checkGate, getConfig and getExperiment. We realized that having user as a nullable parameter was causing confusions for developers, so we've decided to make it required and provide guidance on what to do for different scenarios.

2. Renamed clientVersion to appVersion on StatsigUser to be consistent with the naming on Statsig console and client SDKs.

3. Removed isReady(). Statsig is ready to be used whenever initialize() has finished.

v3.2.0 - Experiments and new initialization options

With version 3.0.0, we introduced SDK ruleset local evaluation so that your checkGate and getConfig calls no longer make a http request each time. Now with version 3.2.0, we are introducing a new API and a few customization options for initialize():

• New API: getExperiment(user: object, experimentName: string).

  • This new API returns a DynamicConfig object that you can use to retrieve parameters for your experiments (you can still use getConfig() if you prefer that).

• 3 new configuration options for StatsigOptions:

  1. environment: an object type parameter which you can use to specify values for targeting purposes for ALL of your users in the current environment. E.g. use {"tier": "staging"} to specify environment tier and test in your staging environment if you have any "Environment Tier" conditions configured.

  2. rulesUpdatedCallback(rulesJSON: string, time: number): a callback that is called every time there is an update to your company's rules. It has two parameters, representing the rules in a JSON string and the version/timestamp of the rules.

  3. bootstrapValues: a string parameter that you can use to bootstrap Statsig's initialization. The value should be a rulesJSON value you get from the callback in 2). In the very rare case that your server cannot reach Statsig during initialization, this will ensure Statsig SDK still can evaluate your feature gates and Dynamic Configs.