All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog and this project adheres to Semantic Versioning.
-
core: if a
./default-env.json
file was present andNODE_ENV !== "production"
, we had assumed that cf env variablesVCAP_APPLCATION
andVCAP_SERVICES
are always present in the file. now this is more resilient. -
core: [regression] initialize timing was noticeably slower, because the initial connection check was running with the default reconnect strategy that takes 2000ms. now the reconnect strategy is disabled for the initial connection check.
- cds-plugin: change default service access role to
internal-user
(fixes #90). - redis: changed dependency from redis to @redis/client.
-
core: [undocumented] plugin-config/initialize support multiple configuration files.
-
redis: [undocumented] cds-config/initialize take redis credentials and client options for fine-tuning or as an alternative to VCAP_SERVICES (brought up by #92).
the cds-config approach is consistent with the redis integration of other cap-js-community projects, see event-queue, websocket.
- cds-plugin: added explicit implementation for
FeatureService
. - enable node v22 voters.
- cds-plugin: allow feature toggles to initialize with no configured toggles.
- use proper cds syntax to get service operations (by johannes-vogel).
- the initialization log of the library will now show the unique name used. this name is used to derive both the redis storage key and pub/sub channel.
- internal naming cleanup and consistency work.
- cds-plugin: service endpoint
/rest/feature/redisRead
will return server in-memory changes in NO_REDIS mode in order to be consistent with/rest/feature/redisUpdate
.
- cds-plugin: added
cds.test()
basic request/response tests for service.
- cds-plugin: service endpoint
/rest/feature/redisRead
works without http errors in NO_REDIS mode.
-
The main class of the library is no longer explicitly exported. You can access it implicitly as constructor of the exported class instance.
// before const { FeatureToggles } = require("@cap-js-community/feature-toggle-library"); const myToggles = new FeatureToggles({ uniqueName: "snowflake" }); // after const toggles = require("@cap-js-community/feature-toggle-library"); const FeatureToggles = toggles.constructor; const myToggles = new FeatureToggles({ uniqueName: "snowflake" });
-
cds-plugin: rewrote
/rest/feature/redisRead
endpoint to show all Redis maintained toggle values, including those of toggles that are not configured. The endpoint no longer refreshes the server-local toggle state. Consequently, it will work withread
access privileges, since it can no longer modify the server-local state (fixes #69).
- added
remoteOnly
option for/rest/feature/redisUpdate
endpoint and thechangeFeatureValue()
API. With this option, you can clean up Redis maintained values that are no longer configured (fixes #69). - cds-plugin: better detection of serve mode following changes in @sap/cds v8.2.3
- multiple, even concurrent, calls of
initializeFeatures()
will only ever trigger one execution of the underlying initialization.
- setting a root value with the option
{ clearSubScopes: true }
only deleted the root and scoped values, but did not set the new root value.
- cds-plugin: fix
uniqueName
configuration processing - more consistent scope preference order when 2 out of 4 scopes are set
- fallback value
null
is no longer allowed (fixes #62). - change handlers no longer receive
null
as new values, they get the actual new value for the relevant scope instead (fixes #64).
- cds-plugin: unify and fix syntax of
context.error
andcontext.reject
for cds service. - change processing is more resilient. for redis message with multiple changes, if one change fails, then subsequent changes will still be processed.
- docs: basic documentation for newest cds-plugin features.
- cds-plugin: better access control (fixes #57).
- redis: better integration mode, will not log a connection error if redis is not present.
- cds-plugin: fts feature toggles are detected and configured automatically (fixes #50).
- cds-plugin: allow custom scope map callback for fts feature toggles (fixes #51).
- cds-plugin: can configure unique name, i.e. which apps store the same toggles in redis, as part of cds configuration.
- cds-plugin: feature toggles will not initialize during cds build.
- redis: proper usage of redis-client built-in reconnect capabilities.
- cds-service: always log update contents for traceability and improved logging for redis read and update errors.
- docs: add getting started section (fixes #43).
require
API and
made it much leaner. These changes should have happened in 1.0, sorry for the inconvenience.
// before
const {
singleton: { getFeatureValue },
} = require("@cap-js-community/feature-toggle-library");
function someFunc() {
getFeatureValue(key);
}
// after
const toggles = require("@cap-js-community/feature-toggle-library");
function someFunc() {
toggles.getFeatureValue(key);
}
For details see https://cap-js-community.github.io/feature-toggle-library/usage/
- the library now exports only the singleton instance (fixes #39).
- cds-plugin: the request header features are only respected in development environments (fixes #41).
We are releasing 1.0, after 2 years of continuous usage, testing, and small improvements.
- restrict to node v18+
- act as Feature Vector Provider when used as a CDS-Plugin.
- allow graceful shutdown by closing redis clients on cds shutdown event (fixes #34).
- support for redis cluster configurations.
- enable setting maximal log level through env variable
BTP_FEATURES_LOG_LEVEL
. this can be used to silence the library during tests.
- implement new CDS-Plugin API, where plugins export a promise instead of an activate property and stay compatible for older cds versions.
- CDS-Plugin integration now works for projects that run
cds build --production
and only use the resultingcsn.json
at runtime.
-
new harmonized validation configuration for scope and regex checks, as well as external validation with user provided modules.
-
new (optional) CDS-Plugin integration. for details, see the new plugin and service documentation.
-
new logger implementation which replaces cf-nodejs-logging-support dependency. it has better cds integration (if present). for example, it will log correlation ids that are present in cds context via async local storage.
-
allowedScopes: [xxx]
configuration will now be ignored and needs to be replaced withvalidations: [{ scopes: [xxx] }]
. -
validation: yyy
configuration will now be ignored and needs to be replaced withvalidations: [{ regex: yyy }]
.
- re-work pipelines to separate main branch and pr-voter status
- example http request file for example-cap-server
-
better documentation regarding scoping and redis hash map persistence
-
more resilient handling of bad input for scopeMaps in all external APIs
- first public release on npmjs
- added
allowedScopes
configuration, which validates that correct scope names are used for updates
- separate
rootValue
from otherscopedValues
ingetFeatureInfo
andgetFeaturesInfos
APIs
- added
example-cap-server
code, that acts both as an example integration code into existing cap projects and as a starting point for manual testing
- first iteration towards updating documentation
- fix bug where scoped values were ignored if they are falsy
- simple migration for old sting-type state to hash-type persistence state
- fix redis transaction re-writes
- remove API to read feature config and metadata
getFeatureConfig
andgetFeatureConfigs
. usegetFeatureInfo
andgetFeaturesInfos
instead
-
new option to add scope restrictions when reading or setting feature toggles
-
separate persistence on redis using
HGET
,HSET
, so that individual toggle changes don't have to touch the state of all feature toggles. effectively we change the redis type for the persistence key fromstring
tohash
. -
new API
getFeatureInfo
andgetFeaturesInfos
to get all config and state information in one call
-
rewrite to improve config handling internally
-
fix some problems with the logger in combination with verror
- restrict to node v16+
- new interface to get
main
andsubscriber
client in redis wrapper
-
better coding and interface for
LazyCache
andExpiringLazyCache
-
more and improved jsdocs
-
allow options to be passed in redis wrapper
set
implementation. see SET for details.
- make logging for warn level work properly
- re-work logging approach so structured logging will capture VError info
-
update feature value is now exclusive under high concurrency (semaphore implementation by oklemenz2)
-
prettier and documentation work better together
- users can rely on always getting fallback value
-
local integration tests
-
write own env implementation replacing @sap/xsenv dependency
- more fixes related to error event handling in local case after redis library v4 migration
- restrict to node v12+
- fix
mainClient
andsubscriberClient
reference handling in error case
- migrate redis dependency to v4
- allow to set singleton
uniqueName
via env variableBTP_FEATURES_UNIQUE_NAME
- fix
readConfigFromFile
for yaml case
- config property
enabled
is discontinued, useactive
instead
-
new config property:
active
. if active is set to false, no changes of the feature toggle is allowed, but old value stays in place -
new API to read feature config and metadata
getFeatureConfig
andgetFeatureConfigs
-
change interface name
readConfigFromFilepath
toreadConfigFromFile
-
change signature for
FeatureValueChangeHandler
tohandler(newValue, oldValue)
- change external validators interface to allow reporting multiple errors
- change validator return interface to ValidationErrors for consistency
-
make singleton more IDE friendly and ensure correctness with test
-
switch to artifactory registry
- feature: external validation
-
readme update
-
handler name fallback for anonymous functions
-
inputValidation is now async to account for potentially async external validators
- Initial public release