Denys Vuika
d70ae599c7
* Update package dependencies: remove unused 'picomatch' and 'minimatch' modules from package-lock.json, and add specific versions for 'picomatch', 'minimatch', 'path-to-regexp', and 'serialize-javascript' in package.json. * Upgrade nx and @nx/workspace to fix minimatch vulnerabilities - Upgrade nx from 22.4.1 to 22.6.3 - Upgrade @nx/workspace from 22.4.5 to 22.6.3 - Remove minimatch override to maintain Karma compatibility This resolves the high severity minimatch vulnerabilities while keeping tests functional. * Refactor nx.json: Consolidate sharedGlobals array and add analytics flag - Merged multiple lines in the sharedGlobals array for better readability. - Added an analytics flag set to false for configuration. * Update package dependencies: bump @nx packages to version 22.6.5 [ci:force] * Add test specifications for feature flags and user initial pipe [ci:force] - Introduced new selectors for feature flag components in `features.directive.spec.ts` and `not-features.directive.spec.ts`. - Added an injectable sanitizer class in `user-initial.pipe.spec.ts` to enhance testing capabilities. - Created a new log file `out.txt` to capture Karma test execution details and warnings.
@alfresco/adf-core/feature-flags
Secondary entry point of @alfresco/adf-core. It can be used by importing from @alfresco/adf-core/feature-flags.
Feature flags (aka feature toggles) are a concept that allow product owners to control the availability of a feature in a particular environment. A product manager may use feature flags to hide a feature that isn't complete yet, roll out a feature to a select set of end-users in order to gather feedback, or coordinate a feature "go live" with marketing and other departments. From a developer perspective, feature flags are an important tool that allows them to continually commit their code even if a feature is not complete, thus a proper feature flag capability is essential to a functional continuous delivery model.
Because this library system is BE/Framework agnostic, it's required to implement the service that manages the retrieval of FeatureFlags and provide it to the AppModule:
@NgModule({
declarations: [AppComponent],
providers: [
{ provide: OverridableFeaturesServiceToken, useClass: <YourCustomFeaturesService> },
{ provide: FeaturesServiceToken, useExisting: OverridableFeaturesServiceToken },
{ provide: FeaturesServiceConfigToken, useValue: <CustomConfiguration> }
],
bootstrap: [AppComponent],
})
export class AppModule {}
<YourCustomFeaturesService> is a service that implements the IFeaturesService interface:
interface IFeaturesService<T = FlagChangeset> {
init(): Observable<T>;
isOn$(key: string): Observable<boolean>;
isOff$(key: string): Observable<boolean>;
getFlags$(): Observable<T>;
}
A FlagChangeset is an Object in which keys are Feature Flag names, and values are the current and previous enabled status for that particular flag. The previous status can be null.
interface FlagChangeset {
[key: string]: {
current: boolean;
previous: boolean | null;
};
}
Optionally, is possible to provide a <CustomConfiguration>
{
storageKey?: string;
helperExposeKeyOnDocument?: string;
}
storageKey: Local Storage key to save feature flags (default: 'feature-flags')
helperExposeKeyOnDocument: browser document key to add commands to enable or disable feature flags from the browser console.
Furher reading: https://hyland.atlassian.net/wiki/spaces/HXP/pages/1308017277/Studio+Management+of+Feature+Flags https://hyland.atlassian.net/wiki/spaces/HXP/pages/1308031390/Developing+frontend+apps+libs+e2es+with+feature+flags