* refactor: remove unused API definition routes
* feat: add support for proxy keys
* feat: support listening for any event
* feat: embed proxy endpoints
* refactor: add an experimental flag for the embedded proxy
This adds support for multi project tokens to be created. Backward compatibility is handled at 3 different layers here:
- The API is made backwards compatible though a permissive data type that accepts either a project?: string or projects?: string[] property, validation is done through JOI here, which ensures that projects and project are not set together. In the case of neither, this defaults to the previous default of ALL_PROJECTS
- The service layer method to handle adding tokens has been made tolerant to either of the above case and has been deprecated, a new method supporting only the new structure of using projects has been added
- Existing compatibility for consumers of Unleash as a library should not be affected either, the ApiUser constructor is now tolerant to the the first input and will internally map to the new cleaned structure
Adds support for initializing a fresh Unleash instance with predefined API tokens.
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
Co-authored-by: Juraj Malenica <juraj.malenica@mindsmiths.com>
Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com>
Our testing and internal validation has proven that
the :global: environment concept confuses people more
than the problems it solves. We have thus decided to
group all configuration that was created before the
environment concept was introduced in to the "default
environment. This would still make everything work
as before in addition to introducing the env concept.
Co-authored-by: Christopher Kolstad <chriswk@getunleash.ai>
feat: options are now typed
- This makes it easier to know what to send to unleash.start / unleash.create
- Using a Partial to instantiate the config, then melding it with defaults to get a config object with all fields set either to their defaults or to whatever is passed in.
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
Co-authored-by: Ivar Conradi Østhus <ivarconr@gmail.com>
