## This PR
- updates the context and trackingEventDetails on the tracking interface
to not be optional since they're always supplied by the SDK.
### Notes
This is a small QoL improvement for provider devs implementing the
tracking interface.
### How to test
The SDK still compiles, and the tests don't need to be modified.
---------
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com>
📣 This was a draft for a while, but is now ready for review! 📣
This implements tracking as per spec, in the server, web, and react
SDKs.
I don't think the Angular or Nest SDKs need specific implementations,
but please advise (cc @luizgribeiro @lukas-reining).
Fixes: https://github.com/open-feature/js-sdk/issues/1033
Fixes: https://github.com/open-feature/js-sdk/issues/1034
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Inspired by [this
comment](https://github.com/open-feature/js-sdk/pull/1020#discussion_r1777829664)
I've added a lint rule to enforce `import type`, and some additional
package changes to add a `lint:fix`.
The only changes I made manually here is to add the lint rule, and the
package.json script. All the changes are auto-generated by the
`lint:fix`.
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
There's no bug here, but this adds some asserts for a tricky bug I
recently found in the Java SDK:
https://github.com/open-feature/java-sdk/pull/1049
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
<!-- Please use this template for your pull request. -->
<!-- Please use the sections that you need and delete other sections -->
## This PR
As discussed here
https://github.com/open-feature/js-sdk/pull/750#discussion_r1450896230,
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.
---------
Signed-off-by: Lukas Reining <lukas.reining@codecentric.de>
<!-- Please use this template for your pull request. -->
<!-- Please use the sections that you need and delete other sections -->
## This PR
<!-- add the description of the PR here -->
Removes OpenFeatureClient class from exports and makes event details
readonly as described here:
https://github.com/open-feature/js-sdk/issues/799
Signed-off-by: Lukas Reining <lukas.reining@codecentric.de>
<!-- Please use this template for your pull request. -->
<!-- Please use the sections that you need and delete other sections -->
## This PR
<!-- add the description of the PR here -->
- removes experimental warning from context propagation js-docs
- improves typing of `setTransactionContext`
- adds `AsyncLocalStorageTransactionContextProvider` to server SDK
- @beeme1mr @toddbaert I am not 100% sure on this one.
To me it makes much sense to add this to the server SDK as it uses the
Node default way `async_hooks`/`async_local_storage` which is part of
Node since Node 16.x. I expect almost every project using the feature,
to build exactly this so I wanted to include it in the SDK.
As we are using Node types anyways I do not see a problem here, but
still we could leave this out as it couples the implementation closer to
Node.
Before merging I will have to change the README.
---------
Signed-off-by: Lukas Reining <lukas.reining@codecentric.de>
Implements the newest spec changes
[here](https://github.com/open-feature/spec/pull/241).
- Provider state is deprecated (state is now maintained in the SDK
itself). This is non-breaking, we just ignore the provider's own state
now
- add RECONCILING events and state, fire related events with provider's
`on context change`
- add FATAL state
The new tests should help you understand the impact of the changes.
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
## This PR
- adds domain as a concept to the server and web SDK
- adds a deprecation warning anywhere client name was exposed to users.
- fixes an issue in the web SDK where context set on a domain before a
provider is registered was not used.
## Addresses
fixes#8204aa965721f
### Notes
This change is based on [this
spec](https://github.com/open-feature/spec/pull/229) change. I tried to
make it a non-breaking change but I may have missed an untested
condition. Please carefully review to make sure I didn't miss anything.
### Follow-up Tasks
- Update the doc readme parser to support "domain".
- Update the NestJS and React SDKS. We should consider making those a
breaking change since they're sub 1.0.
---------
Signed-off-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Co-authored-by: Todd Baert <todd.baert@dynatrace.com>
## This PR
- add provider compatibility check
### Related Issues
<!-- add here the GitHub issue that this PR resolves if applicable -->
Fixes#535
### Notes
This implementation throws if you set a provider that's incompatible
with its intended use. This could easily be changed to a warning if
that's the preferred approach. I think it's a good idea to fail early
but I would be interested in others thoughts on this.
This is a non-breaking change. Providers can optionally specify their
intended use and the SDK will perform a runtime check during provider
registration.
### Follow up
- Add hook compatibility checks.
- Update readme to include examples.
- Update existing providers.
---------
Signed-off-by: Michael Beemer <michael.beemer@dynatrace.com>
<!-- Please use this template for your pull request. -->
<!-- Please use the sections that you need and delete other sections -->
## This PR
Splits up the types file and restructures the SDK by functionalities.
Feeling quite good with the structure now.
The PR became quite huge, but I could even move one or two more things
(for the client) to the shared implementation.
@toddbaert @beeme1mr Please give feedback if you think the structure is
completely off or something seems odd to you🙂
### Related Issues
<!-- add here the GitHub issue that this PR resolves if applicable -->
Fixes#437
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This PR transfroms this repo into a monorepo, with server (exsiting),
client (new) and shared (new) packages.
There are no tests yet for the client. Publishing _should_ work but is
yet untested.
The experimental web SDK will be published as `0.0.1-experimental` and
features:
- native browser events
- "close" functionality (implemented in server as well)
- async context setting
- sync evaluation
Though we want `close` and `events` in the server SDK, they are not
implemented in this PR (though it would be very easy to do so and I've
left TODO's about it). **There are no functional changes in the server
SDK with this PR.**
Here is a [direct
link](https://github.com/open-feature/js-sdk/blob/experimental-web-sdk/README.md)
to the README.md changes.
**_I'm not expecting reviewers to go through this with a fine-toothed
comb. Most of the changes are just establishing the monorepo, and the
functional stuff in the new web-sdk is just experimental._**.
Closes: https://github.com/open-feature/js-sdk/issues/367
---------
Signed-off-by: Todd Baert <toddbaert@gmail.com>
Co-authored-by: Michael Beemer <beeme1mr@users.noreply.github.com>
Michael Beemer