With our recent changes in bundling, there's a new problem with the
framework-specific SDKs (react + nestjs). These have peers, and the
external function was bundling those peers as well, which can cause tsc
errors due to conflicts. This change prevents us from bundling any peers
(which is what we want, so we avoid conflicts with the consumers
installed peers).
This has no runtime impact, and there was no changes to core, web, or
server SDK dists. See image below for the difference in the react SDK
(notice peers are now IMPORTED):
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
My rollup config was invalid, but clumsily working until a recent change
in how we defined the event emitter type. The impact was the the bundled
types for the web imported `from 'events'` instead of bundling it.
This PR fixes the mis-configuration (see comments).
Here is a screenshot showing the bundled types in the dist now (notice
the import is gone and the emitter is in-lined, no other changes are
present):
In server, this type is available from node, so we DON'T need to bundle
it, and in fact, SHOULD import it. This is easily done by importing it
like `from 'node:events'`. I don't think it would be a problem if we
bundled it anyway, but this is more correct.
Fixes: https://github.com/open-feature/js-sdk/issues/845
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
A while back I added:
```json
"paths": {
"@openfeature/core": [ "./packages/shared/src" ]
},
```
To the tsconfigs, which helped with local dev by always resolving
`src/*` files from sibling packages instead of anything in their
`dist/`.
It also had the nasty side-effect of causing our type bundling to
include types from this package in it's output, causing duplicated
artifacts and possible compiler issues. I've overridden this with a
custom `tsconfig.rollup.json`.
Before this fix, the web/server SDK dists contained dupes of the stuff
in shared:
```ts
import EventEmitter from 'events';
type FlagValueType = 'boolean' | 'string' | 'number' | 'object';
type PrimitiveValue = null | boolean | string | number;
type JsonObject = {
[key: string]: JsonValue;
};
type JsonArray = JsonValue[];
/**
* Represents a JSON node value.
*/
```
After this fix, they import them:
```ts
import { BaseHook, HookHints, EvaluationDetails, JsonValue, EvaluationLifeCycle, ManageLogger, Eventing, ClientMetadata, ProviderStatus, ClientProviderEvents, GenericEventEmitter, CommonEventDetails, FlagValue, CommonProvider, EvaluationContext, Logger, ResolutionDetails, EventHandler, OpenFeatureCommonAPI, ManageContext } from '@openfeature/core';
export * from '@openfeature/core';
```
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
This PR addresses: https://github.com/open-feature/js-sdk/issues/616 by:
- configuring CI to release a new module (in addition to
server/web/react we now release the "core" module (previously called
"shared").
- adding a peer dep to the above module to server/web/react
- adding a workflow to ensure that `shared` is released ahead of
associated web/server/react changes, and which also auto-increments the
peer dep version when the core module is released
- unrelated `typedoc` improvements/updates
> [!NOTE]
> I intend to create a new PR that will rename the dir structure
according to the packages... so `shared/` will become `core/` and
`client/` will become `web/`. I just didn't want to add confusion and
noise to this PR.
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
This PR:
- adds all the necessary groundwork for a new react module in the
monorepo (packaging, release, CI, etc)
- adds a _very_ limited implementation based on work by @moredip , see
example in
[README](a9104c1ca2/packages/react/README.md)
Things to note:
- I've chosen NOT to bundle in the web-sdk directly into the react-sdk
(which I could have done). Instead, the web-sdk is a peer dependency.
Reasoning:
- NPM 16+ automatically downloads peer deps if missing, and otherwise
uses the available peer if compatible
- Providers "don't care" whether they are used by the web-sdk, or the
react-sdk, however, they all need a peerDependency on the web-sdk. If we
bundled the web-sdk into the react-sdk automatically, it would mean that
a consumer only using the react-sdk + some-web-provider would get a
"useless" copy of the web-sdk downloaded automatically. For that reason,
it's better to have the web-sdk as a peer, with the react SDK purely
building on to of that dep, not duplicating/embedding a bunch of its
code.
- the web-sdk objects are re-exported from the react-sdk, so consumers
only need to import from there.
relates to: https://github.com/open-feature/js-sdk/pull/546📣 I want to make clear that this is not a final API, and I'd love
to continue discussion in the linked issue on how this could work. We
can merge this PR (and subsequent ones) without releasing so that people
can experiment locally with various APIs, via
[yalc](https://github.com/wclr/yalc) or `npm link`.
---------
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
⚠️ This change only impacts the experimental web-sdk.
This includes an aliased, bundled version of `EventEmitter` so we have
full control over that API/implementation, and consumers don't need the
`events` dep for browsers.
We currently bundle [events](https://www.npmjs.com/package/events) (a
browser polyfill for the node events API) into this package, but a
provider author who wants to implement events in their provider would
need to install that package as well. This removes the need for that.
Interested in others' thoughts.
---------
Signed-off-by: Todd Baert <toddbaert@gmail.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>
Todd Baert