+ {featureStrategyVariantsDisplay}
)}
{change.action === 'deleteStrategy' && (
@@ -215,6 +238,7 @@ export const StrategyChange: VFC<{
}
/>
+ {featureStrategyVariantsDisplay}
)}
diff --git a/frontend/src/component/changeRequest/changeRequest.types.ts b/frontend/src/component/changeRequest/changeRequest.types.ts
index cabd151c8d..c4159aee90 100644
--- a/frontend/src/component/changeRequest/changeRequest.types.ts
+++ b/frontend/src/component/changeRequest/changeRequest.types.ts
@@ -164,7 +164,12 @@ type ChangeRequestEnabled = { enabled: boolean };
type ChangeRequestAddStrategy = Pick<
IFeatureStrategy,
- 'parameters' | 'constraints' | 'segments' | 'title' | 'disabled'
+ | 'parameters'
+ | 'constraints'
+ | 'segments'
+ | 'title'
+ | 'disabled'
+ | 'variants'
> & { name: string };
type ChangeRequestEditStrategy = ChangeRequestAddStrategy & { id: string };
diff --git a/frontend/src/component/common/TooltipResolver/TooltipResolver.tsx b/frontend/src/component/common/TooltipResolver/TooltipResolver.tsx
index 8aea828f5c..d4860ac7ff 100644
--- a/frontend/src/component/common/TooltipResolver/TooltipResolver.tsx
+++ b/frontend/src/component/common/TooltipResolver/TooltipResolver.tsx
@@ -18,7 +18,6 @@ export const TooltipResolver = ({
if (!title && !titleComponent) {
return children;
}
-
if (variant === 'custom') {
return (
diff --git a/frontend/src/component/feature/Dependencies/AddDependency.tsx b/frontend/src/component/feature/Dependencies/AddDependency.tsx
new file mode 100644
index 0000000000..be903f089b
--- /dev/null
+++ b/frontend/src/component/feature/Dependencies/AddDependency.tsx
@@ -0,0 +1,60 @@
+import { Box, styled } from '@mui/material';
+import { trim } from '../../common/util';
+import React, { FC, useState } from 'react';
+import Input from '../../common/Input/Input';
+import { CREATE_FEATURE } from '../../providers/AccessProvider/permissions';
+import PermissionButton from '../../common/PermissionButton/PermissionButton';
+import { useDependentFeaturesApi } from 'hooks/api/actions/useDependentFeaturesApi/useDependentFeaturesApi';
+
+const StyledForm = styled('form')({});
+
+const StyledInputDescription = styled('p')(({ theme }) => ({
+ marginBottom: theme.spacing(1),
+}));
+
+const StyledInput = styled(Input)(({ theme }) => ({
+ marginBottom: theme.spacing(2),
+}));
+
+interface IAddDependencyProps {
+ projectId: string;
+ featureId: string;
+}
+export const AddDependency: FC = ({
+ projectId,
+ featureId,
+}) => {
+ const [parent, setParent] = useState('');
+ const { addDependency } = useDependentFeaturesApi();
+
+ return (
+ {
+ addDependency(featureId, { feature: parent });
+ }}
+ >
+
+ What feature do you want to depend on?
+
+
+ setParent(trim(e.target.value))}
+ />
+ {
+ addDependency(featureId, { feature: parent });
+ }}
+ variant={'outlined'}
+ >
+ Add{' '}
+
+
+
+ );
+};
diff --git a/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverview.tsx b/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverview.tsx
index 98283955d5..0e61d6b7e1 100644
--- a/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverview.tsx
+++ b/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverview.tsx
@@ -12,6 +12,9 @@ import { usePageTitle } from 'hooks/usePageTitle';
import { FeatureOverviewSidePanel } from 'component/feature/FeatureView/FeatureOverview/FeatureOverviewSidePanel/FeatureOverviewSidePanel';
import { useHiddenEnvironments } from 'hooks/useHiddenEnvironments';
import { styled } from '@mui/material';
+import { AddDependency } from '../../Dependencies/AddDependency';
+import { useUiFlag } from 'hooks/useUiFlag';
+import { ConditionallyRender } from 'component/common/ConditionallyRender/ConditionallyRender';
const StyledContainer = styled('div')(({ theme }) => ({
display: 'flex',
@@ -39,6 +42,7 @@ const FeatureOverview = () => {
useHiddenEnvironments();
const onSidebarClose = () => navigate(featurePath);
usePageTitle(featureId);
+ const dependentFeatures = useUiFlag('dependentFeatures');
return (
@@ -50,6 +54,16 @@ const FeatureOverview = () => {
/>
+
+ }
+ />
+
diff --git a/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverviewEnvironments/FeatureOverviewEnvironment/EnvironmentAccordionBody/StrategyDraggableItem/StrategyItem/StrategyItem.tsx b/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverviewEnvironments/FeatureOverviewEnvironment/EnvironmentAccordionBody/StrategyDraggableItem/StrategyItem/StrategyItem.tsx
index d71a619f6d..1cfef9da74 100644
--- a/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverviewEnvironments/FeatureOverviewEnvironment/EnvironmentAccordionBody/StrategyDraggableItem/StrategyItem/StrategyItem.tsx
+++ b/frontend/src/component/feature/FeatureView/FeatureOverview/FeatureOverviewEnvironments/FeatureOverviewEnvironment/EnvironmentAccordionBody/StrategyDraggableItem/StrategyItem/StrategyItem.tsx
@@ -12,6 +12,7 @@ import { ConditionallyRender } from 'component/common/ConditionallyRender/Condit
import { CopyStrategyIconMenu } from './CopyStrategyIconMenu/CopyStrategyIconMenu';
import { StrategyItemContainer } from 'component/common/StrategyItemContainer/StrategyItemContainer';
import MenuStrategyRemove from './MenuStrategyRemove/MenuStrategyRemove';
+import SplitPreviewSlider from 'component/feature/StrategyTypes/SplitPreviewSlider/SplitPreviewSlider';
interface IStrategyItemProps {
environmentId: string;
@@ -86,6 +87,9 @@ export const StrategyItem: FC = ({
}
>
+ {strategy.variants ? (
+
+ ) : null}
);
};
diff --git a/frontend/src/component/feature/StrategyTypes/SplitPreviewSlider/SplitPreviewSlider.tsx b/frontend/src/component/feature/StrategyTypes/SplitPreviewSlider/SplitPreviewSlider.tsx
index 6ddd8425a0..7d761579e8 100644
--- a/frontend/src/component/feature/StrategyTypes/SplitPreviewSlider/SplitPreviewSlider.tsx
+++ b/frontend/src/component/feature/StrategyTypes/SplitPreviewSlider/SplitPreviewSlider.tsx
@@ -1,10 +1,9 @@
import { Box, Typography, styled } from '@mui/material';
+import { ConditionallyRender } from 'component/common/ConditionallyRender/ConditionallyRender';
+import { TooltipResolver } from 'component/common/TooltipResolver/TooltipResolver';
+import { IFeatureVariant } from 'interfaces/featureToggle';
-type SplitPreviewSliderProps = {
- values: number[];
-};
-
-const StyledContainer = styled(Box)(({ theme }) => ({
+const StyledContainer = styled(Box)(() => ({
display: 'flex',
width: '100%',
position: 'relative',
@@ -18,55 +17,188 @@ const StyledTrack = styled(Box)(({ theme }) => ({
overflow: 'hidden',
}));
-const StyledSegment = styled(Box)(({ theme }) => ({
+const StyledSegment = styled(Box)(() => ({
height: '100%',
display: 'flex',
flexDirection: 'column',
alignItems: 'center',
+ width: '100%',
}));
-const StyledSegmentTrack = styled(Box)(({ theme }) => ({
- height: theme.spacing(3),
+const StyledSegmentTrack = styled(Box, {
+ shouldForwardProp: prop => prop !== 'index',
+})<{ index: number }>(({ theme, index }) => ({
+ height: theme.spacing(1.8),
width: '100%',
position: 'relative',
+ background: theme.palette.variants[index % theme.palette.variants.length],
}));
-const SplitPreviewSlider = ({ values }: SplitPreviewSliderProps) => {
- if (values.length < 2) {
+const StyledHeaderContainer = styled(Box)(({ theme }) => ({
+ display: 'flex',
+ alignItems: 'center',
+ marginBottom: theme.spacing(1),
+}));
+
+const StyledTypography = styled(Typography)(({ theme }) => ({
+ marginY: theme.spacing(1),
+}));
+
+const StyledVariantBoxContainer = styled(Box)(() => ({
+ display: 'flex',
+ alignItems: 'center',
+ marginLeft: 'auto',
+}));
+
+const StyledVariantBox = styled(Box, {
+ shouldForwardProp: prop => prop !== 'index',
+})<{ index: number }>(({ theme, index }) => ({
+ display: 'flex',
+ alignItems: 'center',
+ marginRight: theme.spacing(2),
+ '& div': {
+ width: theme.spacing(1.6),
+ height: theme.spacing(1.6),
+ borderRadius: '50%',
+ marginRight: theme.spacing(1),
+ background:
+ theme.palette.variants[index % theme.palette.variants.length],
+ },
+}));
+
+const StyledTypographySubtitle = styled(Typography)(({ theme }) => ({
+ marginTop: theme.spacing(1),
+}));
+
+interface ISplitPreviewSliderProps {
+ variants: IFeatureVariant[];
+}
+
+const SplitPreviewSlider = ({ variants }: ISplitPreviewSliderProps) => {
+ if (variants.length < 2) {
return null;
}
return (
({ marginTop: theme.spacing(2) })}>
- ({ marginY: theme.spacing(1) })}
- >
- Split preview
-
+
- {values.map((value, index) => (
-
- ({
- background:
- theme.palette.variants[
- index % theme.palette.variants.length
- ],
- })}
- />
- ({ marginTop: theme.spacing(1) })}
+
+ {variants.map((variant, index) => {
+ const value = variant.weight / 10;
+ return (
+ e.preventDefault()}
+ titleComponent={
+
+ }
>
- {value}%
-
-
- ))}
+
+ {' '}
+
+
+
+ {value}%
+
+
+
+
+ );
+ })}
);
};
+const SplitPreviewHeader = ({ variants }: ISplitPreviewSliderProps) => {
+ return (
+
+
+ Feature variants ({variants.length})
+
+
+ {variants.map((variant, index) => (
+
+
+
+ {variant.name}
+
+
+ ))}
+
+
+ );
+};
+
+interface ISplitPreviewTooltip {
+ variant: IFeatureVariant;
+ index: number;
+}
+
+const StyledTooltipContainer = styled(Box)(() => ({
+ display: 'flex',
+ flexDirection: 'column',
+}));
+
+const StyledVariantContainer = styled(Box)(() => ({
+ display: 'flex',
+ alignItems: 'center',
+ minWidth: '250px',
+}));
+
+const StyledPayloadContainer = styled(Box)(({ theme }) => ({
+ marginTop: theme.spacing(1),
+ display: 'flex',
+ flexDirection: 'column',
+}));
+
+const StyledPayloadLabel = styled(Typography)(({ theme }) => ({
+ marginBottom: theme.spacing(1),
+}));
+
+const SplitPreviewTooltip = ({ variant, index }: ISplitPreviewTooltip) => {
+ return (
+
+
+
+
+
+
+
+ {variant.weight / 10}% - {variant.name}
+
+
+
+ {variant.payload ? (
+
+
+ Payload
+
+
+ {variant.payload.value}}
+ elseShow={
+
+ {variant.payload.value}
+
+ }
+ />
+
+ ) : null}
+
+ );
+};
+
export default SplitPreviewSlider;
diff --git a/frontend/src/component/feature/StrategyTypes/StrategyVariants.tsx b/frontend/src/component/feature/StrategyTypes/StrategyVariants.tsx
index 7d1cb785a8..30177b6d79 100644
--- a/frontend/src/component/feature/StrategyTypes/StrategyVariants.tsx
+++ b/frontend/src/component/feature/StrategyTypes/StrategyVariants.tsx
@@ -157,9 +157,7 @@ export const StrategyVariants: FC<{
>
Add variant
- variant.weight / 10)}
- />
+
);
};
diff --git a/frontend/src/hooks/api/actions/useDependentFeaturesApi/useDependentFeaturesApi.ts b/frontend/src/hooks/api/actions/useDependentFeaturesApi/useDependentFeaturesApi.ts
new file mode 100644
index 0000000000..f0241caeb7
--- /dev/null
+++ b/frontend/src/hooks/api/actions/useDependentFeaturesApi/useDependentFeaturesApi.ts
@@ -0,0 +1,35 @@
+import useAPI from '../useApi/useApi';
+
+// TODO: generate from orval
+interface IParentFeaturePayload {
+ feature: string;
+}
+export const useDependentFeaturesApi = () => {
+ const { makeRequest, createRequest, errors, loading } = useAPI({
+ propagateErrors: true,
+ });
+
+ const addDependency = async (
+ childFeature: string,
+ parentFeaturePayload: IParentFeaturePayload
+ ) => {
+ const req = createRequest(
+ `/api/admin/projects/default/features/${childFeature}/dependencies`,
+ {
+ method: 'POST',
+ body: JSON.stringify(parentFeaturePayload),
+ }
+ );
+ try {
+ await makeRequest(req.caller, req.id);
+ } catch (e) {
+ throw e;
+ }
+ };
+
+ return {
+ addDependency,
+ errors,
+ loading,
+ };
+};
diff --git a/frontend/src/hooks/api/actions/useFeatureApi/useFeatureApi.ts b/frontend/src/hooks/api/actions/useFeatureApi/useFeatureApi.ts
index 8bd77729c2..4340616588 100644
--- a/frontend/src/hooks/api/actions/useFeatureApi/useFeatureApi.ts
+++ b/frontend/src/hooks/api/actions/useFeatureApi/useFeatureApi.ts
@@ -196,8 +196,12 @@ const useFeatureApi = () => {
type: string,
value: string
) => {
+ const encodedTagPath = `${encodeURIComponent(
+ type
+ )}/${encodeURIComponent(value)}`;
+
// TODO: Change this path to the new API when moved.
- const path = `api/admin/features/${featureId}/tags/${type}/${value}`;
+ const path = `api/admin/features/${featureId}/tags/${encodedTagPath}`;
const req = createRequest(path, {
method: 'DELETE',
});
diff --git a/frontend/src/interfaces/uiConfig.ts b/frontend/src/interfaces/uiConfig.ts
index 290af1e5a6..18ea05fffd 100644
--- a/frontend/src/interfaces/uiConfig.ts
+++ b/frontend/src/interfaces/uiConfig.ts
@@ -65,6 +65,7 @@ export type UiFlags = {
variantTypeNumber?: boolean;
privateProjects?: boolean;
accessOverview?: boolean;
+ dependentFeatures?: boolean;
[key: string]: boolean | Variant | undefined;
};
diff --git a/package.json b/package.json
index 38848e3fc1..47dc40912a 100644
--- a/package.json
+++ b/package.json
@@ -167,7 +167,7 @@
"devDependencies": {
"@apidevtools/swagger-parser": "10.1.0",
"@babel/core": "7.22.17",
- "@swc/core": "1.3.84",
+ "@swc/core": "1.3.83",
"@swc/jest": "0.2.29",
"@types/bcryptjs": "2.4.3",
"@types/cors": "2.8.14",
diff --git a/src/lib/__snapshots__/create-config.test.ts.snap b/src/lib/__snapshots__/create-config.test.ts.snap
index 59a28fd6e8..771f220e82 100644
--- a/src/lib/__snapshots__/create-config.test.ts.snap
+++ b/src/lib/__snapshots__/create-config.test.ts.snap
@@ -103,7 +103,6 @@ exports[`should create default config 1`] = `
"privateProjects": false,
"proPlanAutoCharge": false,
"responseTimeWithAppNameKillSwitch": false,
- "slackAppAddon": false,
"strictSchemaValidation": false,
"variantTypeNumber": false,
},
@@ -142,7 +141,6 @@ exports[`should create default config 1`] = `
"privateProjects": false,
"proPlanAutoCharge": false,
"responseTimeWithAppNameKillSwitch": false,
- "slackAppAddon": false,
"strictSchemaValidation": false,
"variantTypeNumber": false,
},
@@ -164,6 +162,7 @@ exports[`should create default config 1`] = `
"keepExisting": false,
},
"inlineSegmentConstraints": true,
+ "isEnterprise": false,
"listen": {
"host": undefined,
"port": 4242,
diff --git a/src/lib/addons/addon-schema.ts b/src/lib/addons/addon-schema.ts
index dd7b4dcbe6..1e3e0b212e 100644
--- a/src/lib/addons/addon-schema.ts
+++ b/src/lib/addons/addon-schema.ts
@@ -9,7 +9,7 @@ export const addonDefinitionSchema = joi.object().keys({
documentationUrl: joi.string().uri({ scheme: [/https?/] }),
description: joi.string().allow(''),
howTo: joi.string().optional().allow(''),
- deprecated: joi.boolean().optional().default(false),
+ deprecated: joi.string().optional().allow(''),
parameters: joi
.array()
.optional()
diff --git a/src/lib/addons/index.ts b/src/lib/addons/index.ts
index c6376dcd8a..9f88f33faa 100644
--- a/src/lib/addons/index.ts
+++ b/src/lib/addons/index.ts
@@ -16,26 +16,14 @@ export const getAddons: (args: {
unleashUrl: string;
flagResolver: IFlagResolver;
}) => IAddonProviders = ({ getLogger, unleashUrl, flagResolver }) => {
- const slackAppAddonEnabled = flagResolver.isEnabled('slackAppAddon');
-
- const slackAddon = new SlackAddon({ getLogger, unleashUrl });
-
- if (slackAppAddonEnabled) {
- slackAddon.definition.deprecated =
- 'This integration is deprecated. Please try the new Slack App integration instead.';
- }
-
const addons: Addon[] = [
new Webhook({ getLogger }),
- slackAddon,
+ new SlackAddon({ getLogger, unleashUrl }),
+ new SlackAppAddon({ getLogger, unleashUrl }),
new TeamsAddon({ getLogger, unleashUrl }),
new DatadogAddon({ getLogger, unleashUrl, flagResolver }),
];
- if (slackAppAddonEnabled) {
- addons.push(new SlackAppAddon({ getLogger, unleashUrl }));
- }
-
return addons.reduce((map, addon) => {
// eslint-disable-next-line no-param-reassign
map[addon.name] = addon;
diff --git a/src/lib/addons/slack-app-definition.ts b/src/lib/addons/slack-app-definition.ts
index e246f25690..c71b0446fc 100644
--- a/src/lib/addons/slack-app-definition.ts
+++ b/src/lib/addons/slack-app-definition.ts
@@ -11,7 +11,6 @@ import {
FEATURE_STRATEGY_ADD,
FEATURE_METADATA_UPDATED,
FEATURE_PROJECT_CHANGE,
- FEATURE_VARIANTS_UPDATED,
FEATURE_POTENTIALLY_STALE_ON,
FEATURE_ENVIRONMENT_VARIANTS_UPDATED,
} from '../types/events';
@@ -62,7 +61,6 @@ const slackAppDefinition: IAddonDefinition = {
FEATURE_STRATEGY_UPDATE,
FEATURE_STRATEGY_ADD,
FEATURE_METADATA_UPDATED,
- FEATURE_VARIANTS_UPDATED,
FEATURE_PROJECT_CHANGE,
FEATURE_POTENTIALLY_STALE_ON,
],
diff --git a/src/lib/addons/slack-definition.ts b/src/lib/addons/slack-definition.ts
index ebbec92969..e2407b7550 100644
--- a/src/lib/addons/slack-definition.ts
+++ b/src/lib/addons/slack-definition.ts
@@ -22,6 +22,8 @@ const slackDefinition: IAddonDefinition = {
displayName: 'Slack',
description: 'Allows Unleash to post updates to Slack.',
documentationUrl: 'https://docs.getunleash.io/docs/addons/slack',
+ deprecated:
+ 'This integration is deprecated. Please try the new Slack App integration instead.',
alerts: [
{
type: 'warning',
diff --git a/src/lib/create-config.test.ts b/src/lib/create-config.test.ts
index d7057df9b0..0d8b137595 100644
--- a/src/lib/create-config.test.ts
+++ b/src/lib/create-config.test.ts
@@ -471,3 +471,19 @@ test.each(['demo', '/demo', '/demo/'])(
expect(config.server.baseUriPath).toBe('/demo');
},
);
+
+test('Config with enterpriseVersion set and pro environment should set isEnterprise to false', async () => {
+ let config = createConfig({
+ enterpriseVersion: '5.3.0',
+ ui: { environment: 'pro' },
+ });
+ expect(config.isEnterprise).toBe(false);
+});
+
+test('Config with enterpriseVersion set and not pro environment should set isEnterprise to true', async () => {
+ let config = createConfig({
+ enterpriseVersion: '5.3.0',
+ ui: { environment: 'Enterprise' },
+ });
+ expect(config.isEnterprise).toBe(true);
+});
diff --git a/src/lib/create-config.ts b/src/lib/create-config.ts
index a18015f686..80ee6cfcde 100644
--- a/src/lib/create-config.ts
+++ b/src/lib/create-config.ts
@@ -481,6 +481,11 @@ export function createConfig(options: IUnleashOptions): IUnleashConfig {
const clientFeatureCaching = loadClientCachingOptions(options);
const prometheusApi = options.prometheusApi || process.env.PROMETHEUS_API;
+
+ const isEnterprise =
+ Boolean(options.enterpriseVersion) &&
+ ui.environment?.toLowerCase() !== 'pro';
+
return {
db,
session,
@@ -513,6 +518,7 @@ export function createConfig(options: IUnleashOptions): IUnleashConfig {
prometheusApi,
publicFolder: options.publicFolder,
disableScheduler: options.disableScheduler,
+ isEnterprise: isEnterprise,
};
}
diff --git a/src/lib/db/project-store.ts b/src/lib/db/project-store.ts
index 7689409c5c..d2a88a0cc8 100644
--- a/src/lib/db/project-store.ts
+++ b/src/lib/db/project-store.ts
@@ -7,6 +7,7 @@ import {
IFlagResolver,
IProject,
IProjectWithCount,
+ ProjectMode,
} from '../types';
import {
IProjectHealthUpdate,
@@ -49,6 +50,11 @@ export interface IEnvironmentProjectLink {
projectId: string;
}
+export interface ProjectModeCount {
+ mode: ProjectMode;
+ count: number;
+}
+
export interface IProjectMembersCount {
count: number;
project: string;
@@ -551,6 +557,34 @@ class ProjectStore implements IProjectStore {
.then((res) => Number(res[0].count));
}
+ async getProjectModeCounts(): Promise {
+ const result: ProjectModeCount[] = await this.db
+ .select(
+ this.db.raw(
+ `COALESCE(${SETTINGS_TABLE}.project_mode, 'open') as mode`,
+ ),
+ )
+ .count(`${TABLE}.id as count`)
+ .from(`${TABLE}`)
+ .join(
+ `${SETTINGS_TABLE}`,
+ `${TABLE}.id`,
+ `${SETTINGS_TABLE}.project`,
+ )
+ .groupBy(
+ this.db.raw(`COALESCE(${SETTINGS_TABLE}.project_mode, 'open')`),
+ );
+ return result.map(this.mapProjectModeCount);
+ }
+
+ // eslint-disable-next-line @typescript-eslint/explicit-module-boundary-types
+ mapProjectModeCount(row): ProjectModeCount {
+ return {
+ mode: row.mode,
+ count: Number(row.count),
+ };
+ }
+
// eslint-disable-next-line @typescript-eslint/explicit-module-boundary-types
mapLinkRow(row): IEnvironmentProjectLink {
return {
diff --git a/src/lib/features/dependent-features/createDependentFeaturesService.ts b/src/lib/features/dependent-features/createDependentFeaturesService.ts
new file mode 100644
index 0000000000..f0b3afb099
--- /dev/null
+++ b/src/lib/features/dependent-features/createDependentFeaturesService.ts
@@ -0,0 +1,10 @@
+import { Db } from '../../db/db';
+import { DependentFeaturesService } from './dependent-features-service';
+import { DependentFeaturesStore } from './dependent-features-store';
+
+export const createDependentFeaturesService = (
+ db: Db,
+): DependentFeaturesService => {
+ const dependentFeaturesStore = new DependentFeaturesStore(db);
+ return new DependentFeaturesService(dependentFeaturesStore);
+};
diff --git a/src/lib/features/dependent-features/dependent-features-controller.ts b/src/lib/features/dependent-features/dependent-features-controller.ts
index 5604fd3451..495d6139c3 100644
--- a/src/lib/features/dependent-features/dependent-features-controller.ts
+++ b/src/lib/features/dependent-features/dependent-features-controller.ts
@@ -17,6 +17,7 @@ import {
import { IAuthRequest } from '../../routes/unleash-types';
import { InvalidOperationError } from '../../error';
import { DependentFeaturesService } from './dependent-features-service';
+import { TransactionCreator, UnleashTransaction } from '../../db/transaction';
interface FeatureParams {
featureName: string;
@@ -28,11 +29,15 @@ const PATH_DEPENDENCIES = `${PATH_FEATURE}/dependencies`;
type DependentFeaturesServices = Pick<
IUnleashServices,
- 'dependentFeaturesService' | 'openApiService'
+ 'transactionalDependentFeaturesService' | 'openApiService'
>;
export default class DependentFeaturesController extends Controller {
- private dependentFeaturesService: DependentFeaturesService;
+ private transactionalDependentFeaturesService: (
+ db: UnleashTransaction,
+ ) => DependentFeaturesService;
+
+ private readonly startTransaction: TransactionCreator;
private openApiService: OpenApiService;
@@ -42,12 +47,18 @@ export default class DependentFeaturesController extends Controller {
constructor(
config: IUnleashConfig,
- { dependentFeaturesService, openApiService }: DependentFeaturesServices,
+ {
+ transactionalDependentFeaturesService,
+ openApiService,
+ }: DependentFeaturesServices,
+ startTransaction: TransactionCreator,
) {
super(config);
- this.dependentFeaturesService = dependentFeaturesService;
+ this.transactionalDependentFeaturesService =
+ transactionalDependentFeaturesService;
this.openApiService = openApiService;
this.flagResolver = config.flagResolver;
+ this.startTransaction = startTransaction;
this.logger = config.getLogger(
'/dependent-features/dependent-feature-service.ts',
);
@@ -84,13 +95,14 @@ export default class DependentFeaturesController extends Controller {
const { variants, enabled, feature } = req.body;
if (this.config.flagResolver.isEnabled('dependentFeatures')) {
- await this.dependentFeaturesService.upsertFeatureDependency(
- featureName,
- {
+ await this.startTransaction(async (tx) =>
+ this.transactionalDependentFeaturesService(
+ tx,
+ ).upsertFeatureDependency(featureName, {
variants,
enabled,
feature,
- },
+ }),
);
res.status(200).end();
} else {
diff --git a/src/lib/features/dependent-features/dependent-features-service.ts b/src/lib/features/dependent-features/dependent-features-service.ts
index d437a108fe..e68787811c 100644
--- a/src/lib/features/dependent-features/dependent-features-service.ts
+++ b/src/lib/features/dependent-features/dependent-features-service.ts
@@ -1,3 +1,4 @@
+import { InvalidOperationError } from '../../error';
import { CreateDependentFeatureSchema } from '../../openapi';
import { IDependentFeaturesStore } from './dependent-features-store-type';
@@ -17,20 +18,28 @@ export class DependentFeaturesService {
}
async upsertFeatureDependency(
- childFeature: string,
+ child: string,
dependentFeature: CreateDependentFeatureSchema,
): Promise {
- const { enabled, feature, variants } = dependentFeature;
+ const { enabled, feature: parent, variants } = dependentFeature;
+
+ const children = await this.dependentFeaturesStore.getChildren(child);
+ if (children.length > 0) {
+ throw new InvalidOperationError(
+ 'Transitive dependency detected. Cannot add a dependency to the feature that other features depend on.',
+ );
+ }
+
const featureDependency: FeatureDependency =
enabled === false
? {
- parent: feature,
- child: childFeature,
+ parent,
+ child,
enabled,
}
: {
- parent: feature,
- child: childFeature,
+ parent,
+ child,
enabled: true,
variants,
};
diff --git a/src/lib/features/dependent-features/dependent-features-store-type.ts b/src/lib/features/dependent-features/dependent-features-store-type.ts
index f82fbc056f..0a96144fd9 100644
--- a/src/lib/features/dependent-features/dependent-features-store-type.ts
+++ b/src/lib/features/dependent-features/dependent-features-store-type.ts
@@ -2,4 +2,5 @@ import { FeatureDependency } from './dependent-features-service';
export interface IDependentFeaturesStore {
upsert(featureDependency: FeatureDependency): Promise;
+ getChildren(parent: string): Promise;
}
diff --git a/src/lib/features/dependent-features/dependent-features-store.ts b/src/lib/features/dependent-features/dependent-features-store.ts
index cb3574e411..db59c192d4 100644
--- a/src/lib/features/dependent-features/dependent-features-store.ts
+++ b/src/lib/features/dependent-features/dependent-features-store.ts
@@ -5,6 +5,7 @@ import { IDependentFeaturesStore } from './dependent-features-store-type';
type SerializableFeatureDependency = Omit & {
variants?: string;
};
+
export class DependentFeaturesStore implements IDependentFeaturesStore {
private db: Db;
@@ -28,4 +29,13 @@ export class DependentFeaturesStore implements IDependentFeaturesStore {
.onConflict(['parent', 'child'])
.merge();
}
+
+ async getChildren(parent: string): Promise {
+ const rows = await this.db('dependent_features').where(
+ 'parent',
+ parent,
+ );
+
+ return rows.map((row) => row.child);
+ }
}
diff --git a/src/lib/features/dependent-features/dependent.features.e2e.test.ts b/src/lib/features/dependent-features/dependent.features.e2e.test.ts
index d1b0503cce..501d150f3c 100644
--- a/src/lib/features/dependent-features/dependent.features.e2e.test.ts
+++ b/src/lib/features/dependent-features/dependent.features.e2e.test.ts
@@ -32,13 +32,13 @@ afterAll(async () => {
});
const addFeatureDependency = async (
- parentFeature: string,
+ childFeature: string,
payload: CreateDependentFeatureSchema,
expectedCode = 200,
) => {
return app.request
.post(
- `/api/admin/projects/default/features/${parentFeature}/dependencies`,
+ `/api/admin/projects/default/features/${childFeature}/dependencies`,
)
.send(payload)
.expect(expectedCode);
@@ -51,13 +51,33 @@ test('should add feature dependency', async () => {
await app.createFeature(child);
// save explicit enabled and variants
- await addFeatureDependency(parent, {
- feature: child,
+ await addFeatureDependency(child, {
+ feature: parent,
enabled: false,
});
// overwrite with implicit enabled: true and variants
- await addFeatureDependency(parent, {
- feature: child,
+ await addFeatureDependency(child, {
+ feature: parent,
variants: ['variantB'],
});
});
+
+test('should not allow to add a parent dependency to a feature that already has children', async () => {
+ const grandparent = uuidv4();
+ const parent = uuidv4();
+ const child = uuidv4();
+ await app.createFeature(grandparent);
+ await app.createFeature(parent);
+ await app.createFeature(child);
+
+ await addFeatureDependency(child, {
+ feature: parent,
+ });
+ await addFeatureDependency(
+ parent,
+ {
+ feature: grandparent,
+ },
+ 403,
+ );
+});
diff --git a/src/lib/features/dependent-features/fake-dependent-features-store.ts b/src/lib/features/dependent-features/fake-dependent-features-store.ts
index 27c7eb4a73..c338ccc1b3 100644
--- a/src/lib/features/dependent-features/fake-dependent-features-store.ts
+++ b/src/lib/features/dependent-features/fake-dependent-features-store.ts
@@ -4,4 +4,8 @@ export class FakeDependentFeaturesStore implements IDependentFeaturesStore {
async upsert(): Promise {
return Promise.resolve();
}
+
+ getChildren(): Promise {
+ return Promise.resolve([]);
+ }
}
diff --git a/src/lib/features/instance-stats/instance-stats-service.ts b/src/lib/features/instance-stats/instance-stats-service.ts
index 901eb1604b..9cce8af42c 100644
--- a/src/lib/features/instance-stats/instance-stats-service.ts
+++ b/src/lib/features/instance-stats/instance-stats-service.ts
@@ -20,6 +20,7 @@ import { ISettingStore } from '../../types/stores/settings-store';
import { FEATURES_EXPORTED, FEATURES_IMPORTED } from '../../types';
import { CUSTOM_ROOT_ROLE_TYPE } from '../../util';
import { type GetActiveUsers } from './getActiveUsers';
+import { ProjectModeCount } from '../../db/project-store';
export type TimeRange = 'allTime' | '30d' | '7d';
@@ -30,7 +31,7 @@ export interface InstanceStats {
versionEnterprise?: string;
users: number;
featureToggles: number;
- projects: number;
+ projects: ProjectModeCount[];
contextFields: number;
roles: number;
customRootRoles: number;
@@ -47,9 +48,10 @@ export interface InstanceStats {
activeUsers: Awaited>;
}
-export interface InstanceStatsSigned extends InstanceStats {
+export type InstanceStatsSigned = Omit & {
+ projects: number;
sum: string;
-}
+};
export class InstanceStatsService {
private logger: Logger;
@@ -152,6 +154,10 @@ export class InstanceStatsService {
}
}
+ getProjectModeCount(): Promise {
+ return this.projectStore.getProjectModeCounts();
+ }
+
getToggleCount(): Promise {
return this.featureToggleStore.count({
archived: false,
@@ -201,7 +207,7 @@ export class InstanceStatsService {
this.getToggleCount(),
this.userStore.count(),
this.getActiveUsers(),
- this.projectStore.count(),
+ this.getProjectModeCount(),
this.contextFieldStore.count(),
this.groupStore.count(),
this.roleStore.count(),
@@ -275,10 +281,13 @@ export class InstanceStatsService {
async getSignedStats(): Promise {
const instanceStats = await this.getStats();
+ const totalProjects = instanceStats.projects
+ .map((p) => p.count)
+ .reduce((a, b) => a + b, 0);
const sum = sha256(
- `${instanceStats.instanceId}${instanceStats.users}${instanceStats.featureToggles}${instanceStats.projects}${instanceStats.roles}${instanceStats.groups}${instanceStats.environments}${instanceStats.segments}`,
+ `${instanceStats.instanceId}${instanceStats.users}${instanceStats.featureToggles}${totalProjects}${instanceStats.roles}${instanceStats.groups}${instanceStats.environments}${instanceStats.segments}`,
);
- return { ...instanceStats, sum };
+ return { ...instanceStats, sum, projects: totalProjects };
}
}
diff --git a/src/lib/features/playground/playground-service.ts b/src/lib/features/playground/playground-service.ts
index 4ffcf8d813..4dbb64f42c 100644
--- a/src/lib/features/playground/playground-service.ts
+++ b/src/lib/features/playground/playground-service.ts
@@ -102,17 +102,19 @@ export class PlaygroundService {
let filteredProjects: typeof projects;
if (this.flagResolver.isEnabled('privateProjects')) {
- const accessibleProjects =
+ const projectAccess =
await this.privateProjectChecker.getUserAccessibleProjects(
userId,
);
- filteredProjects =
- projects === ALL
- ? accessibleProjects
- : projects.filter((project) =>
- accessibleProjects.includes(project),
- );
- console.log(accessibleProjects);
+ if (projectAccess.mode === 'all') {
+ filteredProjects = projects;
+ } else if (projects === ALL) {
+ filteredProjects = projectAccess.projects;
+ } else {
+ filteredProjects = projects.filter((project) =>
+ projectAccess.projects.includes(project),
+ );
+ }
}
const environmentFeatures = await Promise.all(
diff --git a/src/lib/features/private-project/createPrivateProjectChecker.ts b/src/lib/features/private-project/createPrivateProjectChecker.ts
index 4844025ca9..7000815dcb 100644
--- a/src/lib/features/private-project/createPrivateProjectChecker.ts
+++ b/src/lib/features/private-project/createPrivateProjectChecker.ts
@@ -10,9 +10,12 @@ export const createPrivateProjectChecker = (
const { getLogger } = config;
const privateProjectStore = new PrivateProjectStore(db, getLogger);
- return new PrivateProjectChecker({
- privateProjectStore: privateProjectStore,
- });
+ return new PrivateProjectChecker(
+ {
+ privateProjectStore: privateProjectStore,
+ },
+ config,
+ );
};
export const createFakePrivateProjectChecker =
diff --git a/src/lib/features/private-project/fakePrivateProjectChecker.ts b/src/lib/features/private-project/fakePrivateProjectChecker.ts
index 2dba73db65..f538908473 100644
--- a/src/lib/features/private-project/fakePrivateProjectChecker.ts
+++ b/src/lib/features/private-project/fakePrivateProjectChecker.ts
@@ -1,9 +1,10 @@
import { IPrivateProjectChecker } from './privateProjectCheckerType';
import { Promise } from 'ts-toolbelt/out/Any/Promise';
+import { ProjectAccess } from './privateProjectStore';
export class FakePrivateProjectChecker implements IPrivateProjectChecker {
// eslint-disable-next-line @typescript-eslint/no-unused-vars
- async getUserAccessibleProjects(userId: number): Promise {
+ async getUserAccessibleProjects(userId: number): Promise {
throw new Error('Method not implemented.');
}
diff --git a/src/lib/features/private-project/privateProjectChecker.ts b/src/lib/features/private-project/privateProjectChecker.ts
index daa30a1a51..2af389a8f7 100644
--- a/src/lib/features/private-project/privateProjectChecker.ts
+++ b/src/lib/features/private-project/privateProjectChecker.ts
@@ -1,26 +1,35 @@
-import { IUnleashStores } from '../../types';
+import { IUnleashConfig, IUnleashStores } from '../../types';
import { IPrivateProjectStore } from './privateProjectStoreType';
import { IPrivateProjectChecker } from './privateProjectCheckerType';
+import { ALL_PROJECT_ACCESS, ProjectAccess } from './privateProjectStore';
export class PrivateProjectChecker implements IPrivateProjectChecker {
private privateProjectStore: IPrivateProjectStore;
- constructor({
- privateProjectStore,
- }: Pick) {
+ private isEnterprise: boolean;
+
+ constructor(
+ { privateProjectStore }: Pick,
+ { isEnterprise }: Pick,
+ ) {
this.privateProjectStore = privateProjectStore;
+ this.isEnterprise = isEnterprise;
}
- async getUserAccessibleProjects(userId: number): Promise {
- return this.privateProjectStore.getUserAccessibleProjects(userId);
+ async getUserAccessibleProjects(userId: number): Promise {
+ return this.isEnterprise
+ ? this.privateProjectStore.getUserAccessibleProjects(userId)
+ : Promise.resolve(ALL_PROJECT_ACCESS);
}
async hasAccessToProject(
userId: number,
projectId: string,
): Promise {
- return (await this.getUserAccessibleProjects(userId)).includes(
- projectId,
+ const projectAccess = await this.getUserAccessibleProjects(userId);
+ return (
+ projectAccess.mode === 'all' ||
+ projectAccess.projects.includes(projectId)
);
}
}
diff --git a/src/lib/features/private-project/privateProjectCheckerType.ts b/src/lib/features/private-project/privateProjectCheckerType.ts
index c8b537a906..8ddb3b9ce4 100644
--- a/src/lib/features/private-project/privateProjectCheckerType.ts
+++ b/src/lib/features/private-project/privateProjectCheckerType.ts
@@ -1,4 +1,6 @@
+import { ProjectAccess } from './privateProjectStore';
+
export interface IPrivateProjectChecker {
- getUserAccessibleProjects(userId: number): Promise;
+ getUserAccessibleProjects(userId: number): Promise;
hasAccessToProject(userId: number, projectId: string): Promise;
}
diff --git a/src/lib/features/private-project/privateProjectStore.ts b/src/lib/features/private-project/privateProjectStore.ts
index 0a3be0b48a..9666cfe9e3 100644
--- a/src/lib/features/private-project/privateProjectStore.ts
+++ b/src/lib/features/private-project/privateProjectStore.ts
@@ -1,8 +1,20 @@
import { Db } from '../../db/db';
import { Logger, LogProvider } from '../../logger';
import { IPrivateProjectStore } from './privateProjectStoreType';
+import { ADMIN_TOKEN_ID } from '../../types';
-const ADMIN_TOKEN_ID = -1;
+export type ProjectAccess =
+ | {
+ mode: 'all';
+ }
+ | {
+ mode: 'limited';
+ projects: string[];
+ };
+
+export const ALL_PROJECT_ACCESS: ProjectAccess = {
+ mode: 'all',
+};
class PrivateProjectStore implements IPrivateProjectStore {
private db: Db;
@@ -16,10 +28,9 @@ class PrivateProjectStore implements IPrivateProjectStore {
destroy(): void {}
- async getUserAccessibleProjects(userId: number): Promise {
+ async getUserAccessibleProjects(userId: number): Promise {
if (userId === ADMIN_TOKEN_ID) {
- const allProjects = await this.db('projects').pluck('id');
- return allProjects;
+ return ALL_PROJECT_ACCESS;
}
const isViewer = await this.db('role_user')
.join('roles', 'role_user.role_id', 'roles.id')
@@ -32,11 +43,10 @@ class PrivateProjectStore implements IPrivateProjectStore {
.first();
if (!isViewer || isViewer.count == 0) {
- const allProjects = await this.db('projects').pluck('id');
- return allProjects;
+ return ALL_PROJECT_ACCESS;
}
- const accessibleProjects = await this.db
+ const accessibleProjects: string[] = await this.db
.from((db) => {
db.distinct()
.select('projects.id as project_id')
@@ -46,7 +56,15 @@ class PrivateProjectStore implements IPrivateProjectStore {
'projects.id',
'project_settings.project',
)
- .where('project_settings.project_mode', '!=', 'private')
+ .where((builder) => {
+ builder
+ .whereNull('project_settings.project')
+ .orWhere(
+ 'project_settings.project_mode',
+ '!=',
+ 'private',
+ );
+ })
.unionAll((queryBuilder) => {
queryBuilder
.select('projects.id as project_id')
@@ -89,7 +107,7 @@ class PrivateProjectStore implements IPrivateProjectStore {
.select('*')
.pluck('project_id');
- return accessibleProjects;
+ return { mode: 'limited', projects: accessibleProjects };
}
}
diff --git a/src/lib/features/private-project/privateProjectStoreType.ts b/src/lib/features/private-project/privateProjectStoreType.ts
index a554aaab5a..98b213775f 100644
--- a/src/lib/features/private-project/privateProjectStoreType.ts
+++ b/src/lib/features/private-project/privateProjectStoreType.ts
@@ -1,3 +1,5 @@
+import { ProjectAccess } from './privateProjectStore';
+
export interface IPrivateProjectStore {
- getUserAccessibleProjects(userId: number): Promise;
+ getUserAccessibleProjects(userId: number): Promise;
}
diff --git a/src/lib/metrics.ts b/src/lib/metrics.ts
index 18c8824ffd..fbdc89937a 100644
--- a/src/lib/metrics.ts
+++ b/src/lib/metrics.ts
@@ -105,6 +105,7 @@ export default class MetricsMonitor {
const projectsTotal = new client.Gauge({
name: 'projects_total',
help: 'Number of projects',
+ labelNames: ['mode'],
});
const environmentsTotal = new client.Gauge({
name: 'environments_total',
@@ -193,7 +194,11 @@ export default class MetricsMonitor {
usersActive90days.set(stats.activeUsers.last90);
projectsTotal.reset();
- projectsTotal.set(stats.projects);
+ stats.projects.forEach((projectStat) => {
+ projectsTotal
+ .labels({ mode: projectStat.mode })
+ .set(projectStat.count);
+ });
environmentsTotal.reset();
environmentsTotal.set(stats.environments);
diff --git a/src/lib/routes/admin-api/instance-admin.ts b/src/lib/routes/admin-api/instance-admin.ts
index 02610a3e69..9b8a343e75 100644
--- a/src/lib/routes/admin-api/instance-admin.ts
+++ b/src/lib/routes/admin-api/instance-admin.ts
@@ -7,7 +7,6 @@ import Controller from '../controller';
import { NONE } from '../../types/permissions';
import { UiConfigSchema } from '../../openapi/spec/ui-config-schema';
import {
- InstanceStats,
InstanceStatsService,
InstanceStatsSigned,
} from '../../features/instance-stats/instance-stats-service';
@@ -97,7 +96,7 @@ class InstanceAdminController extends Controller {
featureToggles: 29,
groups: 3,
instanceId: 'ed3861ae-78f9-4e8c-8e57-b57efc15f82b',
- projects: 1,
+ projects: 4,
roles: 5,
customRootRoles: 2,
customRootRolesInUse: 1,
@@ -119,7 +118,7 @@ class InstanceAdminController extends Controller {
async getStatistics(
req: AuthedRequest,
- res: Response,
+ res: Response,
): Promise {
const instanceStats = await this.instanceStatsService.getSignedStats();
res.json(instanceStats);
diff --git a/src/lib/routes/admin-api/project/index.ts b/src/lib/routes/admin-api/project/index.ts
index 90ae03a60f..15f5d83700 100644
--- a/src/lib/routes/admin-api/project/index.ts
+++ b/src/lib/routes/admin-api/project/index.ts
@@ -113,7 +113,14 @@ export default class ProjectApi extends Controller {
createKnexTransactionStarter(db),
).router,
);
- this.use('/', new DependentFeaturesController(config, services).router);
+ this.use(
+ '/',
+ new DependentFeaturesController(
+ config,
+ services,
+ createKnexTransactionStarter(db),
+ ).router,
+ );
this.use('/', new EnvironmentsController(config, services).router);
this.use('/', new ProjectHealthReport(config, services).router);
this.use('/', new VariantsController(config, services).router);
diff --git a/src/lib/services/client-metrics/instance-service.ts b/src/lib/services/client-metrics/instance-service.ts
index 19cca5a26b..f819dc486e 100644
--- a/src/lib/services/client-metrics/instance-service.ts
+++ b/src/lib/services/client-metrics/instance-service.ts
@@ -184,16 +184,22 @@ export default class ClientInstanceService {
await this.privateProjectChecker.getUserAccessibleProjects(
userId,
);
- return applications.map((application) => {
- return {
- ...application,
- usage: application.usage?.filter(
- (usageItem) =>
- usageItem.project === ALL_PROJECTS ||
- accessibleProjects.includes(usageItem.project),
- ),
- };
- });
+ if (accessibleProjects.mode === 'all') {
+ return applications;
+ } else {
+ return applications.map((application) => {
+ return {
+ ...application,
+ usage: application.usage?.filter(
+ (usageItem) =>
+ usageItem.project === ALL_PROJECTS ||
+ accessibleProjects.projects.includes(
+ usageItem.project,
+ ),
+ ),
+ };
+ });
+ }
}
return applications;
}
diff --git a/src/lib/services/feature-toggle-service.ts b/src/lib/services/feature-toggle-service.ts
index 17b35c2596..6bb6bd3a62 100644
--- a/src/lib/services/feature-toggle-service.ts
+++ b/src/lib/services/feature-toggle-service.ts
@@ -1031,11 +1031,15 @@ class FeatureToggleService {
});
if (this.flagResolver.isEnabled('privateProjects') && userId) {
- const projects =
+ const projectAccess =
await this.privateProjectChecker.getUserAccessibleProjects(
userId,
);
- return features.filter((f) => projects.includes(f.project));
+ return projectAccess.mode === 'all'
+ ? features
+ : features.filter((f) =>
+ projectAccess.projects.includes(f.project),
+ );
}
return features;
}
@@ -1860,11 +1864,17 @@ class FeatureToggleService {
): Promise {
const features = await this.featureToggleStore.getAll({ archived });
if (this.flagResolver.isEnabled('privateProjects')) {
- const projects =
+ const projectAccess =
await this.privateProjectChecker.getUserAccessibleProjects(
userId,
);
- return features.filter((f) => projects.includes(f.project));
+ if (projectAccess.mode === 'all') {
+ return features;
+ } else {
+ return features.filter((f) =>
+ projectAccess.projects.includes(f.project),
+ );
+ }
}
return features;
}
diff --git a/src/lib/services/group-service.ts b/src/lib/services/group-service.ts
index 589a5707ba..ea4e652252 100644
--- a/src/lib/services/group-service.ts
+++ b/src/lib/services/group-service.ts
@@ -11,7 +11,7 @@ import { IUnleashConfig, IUnleashStores } from '../types';
import { IGroupStore } from '../types/stores/group-store';
import { Logger } from '../logger';
import BadDataError from '../error/bad-data-error';
-import { GROUP_CREATED, GROUP_UPDATED } from '../types/events';
+import { GROUP_CREATED, GROUP_DELETED, GROUP_UPDATED } from '../types/events';
import { IEventStore } from '../types/stores/event-store';
import NameExistsError from '../error/name-exists-error';
import { IAccountStore } from '../types/stores/account-store';
@@ -170,8 +170,16 @@ export class GroupService {
return [];
}
- async deleteGroup(id: number): Promise {
- return this.groupStore.delete(id);
+ async deleteGroup(id: number, userName: string): Promise {
+ const group = await this.groupStore.get(id);
+
+ await this.groupStore.delete(id);
+
+ await this.eventStore.store({
+ type: GROUP_DELETED,
+ createdBy: userName,
+ data: group,
+ });
}
async validateGroup(
diff --git a/src/lib/services/index.ts b/src/lib/services/index.ts
index a3db29e6cf..6a8899e998 100644
--- a/src/lib/services/index.ts
+++ b/src/lib/services/index.ts
@@ -69,6 +69,7 @@ import {
createGetActiveUsers,
} from '../features/instance-stats/getActiveUsers';
import { DependentFeaturesService } from '../features/dependent-features/dependent-features-service';
+import { createDependentFeaturesService } from '../features/dependent-features/createDependentFeaturesService';
// TODO: will be moved to scheduler feature directory
export const scheduleServices = async (
@@ -201,6 +202,7 @@ export const createServices = (
changeRequestAccessReadModel,
config,
);
+
const privateProjectChecker = db
? createPrivateProjectChecker(db, config)
: createFakePrivateProjectChecker();
@@ -298,6 +300,8 @@ export const createServices = (
const dependentFeaturesService = new DependentFeaturesService(
stores.dependentFeaturesStore,
);
+ const transactionalDependentFeaturesService = (txDb: Knex.Transaction) =>
+ createDependentFeaturesService(txDb);
return {
accessService,
@@ -350,6 +354,7 @@ export const createServices = (
transactionalGroupService,
privateProjectChecker,
dependentFeaturesService,
+ transactionalDependentFeaturesService,
};
};
diff --git a/src/lib/services/project-service.ts b/src/lib/services/project-service.ts
index 41cf1334a3..ba2c76677a 100644
--- a/src/lib/services/project-service.ts
+++ b/src/lib/services/project-service.ts
@@ -164,13 +164,18 @@ export default class ProjectService {
): Promise {
const projects = await this.store.getProjectsWithCounts(query, userId);
if (this.flagResolver.isEnabled('privateProjects') && userId) {
- const accessibleProjects =
+ const projectAccess =
await this.privateProjectChecker.getUserAccessibleProjects(
userId,
);
- return projects.filter((project) =>
- accessibleProjects.includes(project.id),
- );
+
+ if (projectAccess.mode === 'all') {
+ return projects;
+ } else {
+ return projects.filter((project) =>
+ projectAccess.projects.includes(project.id),
+ );
+ }
}
return projects;
}
diff --git a/src/lib/types/events.ts b/src/lib/types/events.ts
index 68064d5c26..0ea5d04e20 100644
--- a/src/lib/types/events.ts
+++ b/src/lib/types/events.ts
@@ -90,6 +90,7 @@ export const SEGMENT_UPDATED = 'segment-updated' as const;
export const SEGMENT_DELETED = 'segment-deleted' as const;
export const GROUP_CREATED = 'group-created' as const;
export const GROUP_UPDATED = 'group-updated' as const;
+export const GROUP_DELETED = 'group-deleted' as const;
export const SETTING_CREATED = 'setting-created' as const;
export const SETTING_UPDATED = 'setting-updated' as const;
export const SETTING_DELETED = 'setting-deleted' as const;
@@ -213,6 +214,7 @@ export const IEventTypes = [
SEGMENT_DELETED,
GROUP_CREATED,
GROUP_UPDATED,
+ GROUP_DELETED,
SETTING_CREATED,
SETTING_UPDATED,
SETTING_DELETED,
diff --git a/src/lib/types/experimental.ts b/src/lib/types/experimental.ts
index d7dd19770f..907989dd49 100644
--- a/src/lib/types/experimental.ts
+++ b/src/lib/types/experimental.ts
@@ -20,7 +20,6 @@ export type IFlagKey =
| 'disableBulkToggle'
| 'disableNotifications'
| 'advancedPlayground'
- | 'slackAppAddon'
| 'filterInvalidClientMetrics'
| 'lastSeenByEnvironment'
| 'customRootRolesKillSwitch'
@@ -99,10 +98,6 @@ const flags: IFlags = {
process.env.DISABLE_NOTIFICATIONS,
false,
),
- slackAppAddon: parseEnvVarBoolean(
- process.env.UNLEASH_SLACK_APP_ADDON,
- false,
- ),
filterInvalidClientMetrics: parseEnvVarBoolean(
process.env.FILTER_INVALID_CLIENT_METRICS,
false,
diff --git a/src/lib/types/no-auth-user.ts b/src/lib/types/no-auth-user.ts
index fbb65e8cde..7ceb1fc424 100644
--- a/src/lib/types/no-auth-user.ts
+++ b/src/lib/types/no-auth-user.ts
@@ -1,5 +1,6 @@
import { ADMIN } from './permissions';
+export const ADMIN_TOKEN_ID = -1;
export default class NoAuthUser {
isAPI: boolean;
@@ -11,7 +12,7 @@ export default class NoAuthUser {
constructor(
username: string = 'unknown',
- id: number = -1,
+ id: number = ADMIN_TOKEN_ID,
permissions: string[] = [ADMIN],
) {
this.isAPI = true;
diff --git a/src/lib/types/option.ts b/src/lib/types/option.ts
index d6d85358ad..a948c7e800 100644
--- a/src/lib/types/option.ts
+++ b/src/lib/types/option.ts
@@ -215,4 +215,5 @@ export interface IUnleashConfig {
prometheusApi?: string;
publicFolder?: string;
disableScheduler?: boolean;
+ isEnterprise: boolean;
}
diff --git a/src/lib/types/services.ts b/src/lib/types/services.ts
index e929b06c12..d9e6740280 100644
--- a/src/lib/types/services.ts
+++ b/src/lib/types/services.ts
@@ -101,4 +101,7 @@ export interface IUnleashServices {
transactionalGroupService: (db: Knex.Transaction) => GroupService;
privateProjectChecker: IPrivateProjectChecker;
dependentFeaturesService: DependentFeaturesService;
+ transactionalDependentFeaturesService: (
+ db: Knex.Transaction,
+ ) => DependentFeaturesService;
}
diff --git a/src/lib/types/stores/project-store.ts b/src/lib/types/stores/project-store.ts
index dd565298a9..da6e8cfeb1 100644
--- a/src/lib/types/stores/project-store.ts
+++ b/src/lib/types/stores/project-store.ts
@@ -1,6 +1,7 @@
import {
IEnvironmentProjectLink,
IProjectMembersCount,
+ ProjectModeCount,
} from '../../db/project-store';
import {
IEnvironment,
@@ -32,21 +33,6 @@ export interface IProjectSettings {
featureNamingDescription?: string;
}
-export interface IProjectSettingsRow {
- project_mode: ProjectMode;
- default_stickiness: string;
-}
-
-export interface IProjectEnvironmenDefaultStrategyRow {
- environment: string;
- default_strategy: any;
-}
-
-export interface IProjectArchived {
- id: string;
- archived: boolean;
-}
-
export interface IProjectHealthUpdate {
id: string;
health: number;
@@ -115,6 +101,7 @@ export interface IProjectStore extends Store {
projectId: string,
environment: string,
): Promise;
+
updateDefaultStrategy(
projectId: string,
environment: string,
@@ -122,4 +109,6 @@ export interface IProjectStore extends Store {
): Promise;
isFeatureLimitReached(id: string): Promise;
+
+ getProjectModeCounts(): Promise;
}
diff --git a/src/server-dev.ts b/src/server-dev.ts
index 41e7ed2177..b997164923 100644
--- a/src/server-dev.ts
+++ b/src/server-dev.ts
@@ -37,7 +37,6 @@ process.nextTick(async () => {
embedProxyFrontend: true,
anonymiseEventLog: false,
responseTimeWithAppNameKillSwitch: false,
- slackAppAddon: true,
lastSeenByEnvironment: true,
featureNamingPattern: true,
doraMetrics: true,
@@ -45,6 +44,7 @@ process.nextTick(async () => {
privateProjects: true,
accessOverview: true,
datadogJsonTemplate: true,
+ dependentFeatures: true,
},
},
authentication: {
diff --git a/src/test/e2e/api/admin/addon.e2e.test.ts b/src/test/e2e/api/admin/addon.e2e.test.ts
index 5ead1b23dd..595de3cf21 100644
--- a/src/test/e2e/api/admin/addon.e2e.test.ts
+++ b/src/test/e2e/api/admin/addon.e2e.test.ts
@@ -13,7 +13,6 @@ beforeAll(async () => {
experimental: {
flags: {
strictSchemaValidation: true,
- slackAppAddon: true,
},
},
});
diff --git a/src/test/fixtures/fake-project-store.ts b/src/test/fixtures/fake-project-store.ts
index 0645cda6a9..28eae24098 100644
--- a/src/test/fixtures/fake-project-store.ts
+++ b/src/test/fixtures/fake-project-store.ts
@@ -9,6 +9,7 @@ import NotFoundError from '../../lib/error/notfound-error';
import {
IEnvironmentProjectLink,
IProjectMembersCount,
+ ProjectModeCount,
} from 'lib/db/project-store';
import { CreateFeatureStrategySchema } from '../../lib/openapi';
@@ -185,4 +186,8 @@ export default class FakeProjectStore implements IProjectStore {
isFeatureLimitReached(id: string): Promise {
return Promise.resolve(false);
}
+
+ getProjectModeCounts(): Promise {
+ return Promise.resolve([]);
+ }
}
diff --git a/website/docs/about-the-docs.md b/website/docs/about-the-docs.md
index eeb0a80411..4ced12d815 100644
--- a/website/docs/about-the-docs.md
+++ b/website/docs/about-the-docs.md
@@ -14,10 +14,10 @@ Have questions that you can't find the answer to in these docs? You can always t
Our documentation is split into four parts, using the [Diátaxis documentation framework](https://diataxis.fr/):
-- [tutorials and introductory material](#tutorials)
-- [how-to guides](#how-to-guides)
-- [reference documentation](#reference-documentation)
-- [topic guides](#topic-guides)
+- [Tutorials and introductory material](#tutorials)
+- [How-to guides](#how-to-guides)
+- [Reference documentation](#reference-documentation)
+- [Topic guides](#topic-guides)
### Tutorials and introductory material {#tutorials}
diff --git a/website/docs/reference/integrations/integrations.md b/website/docs/reference/integrations/integrations.md
index 9cfece40b0..1d96c1de51 100644
--- a/website/docs/reference/integrations/integrations.md
+++ b/website/docs/reference/integrations/integrations.md
@@ -24,7 +24,7 @@ Unleash currently supports the following integrations out of the box:
- [Jira Cloud](jira-cloud-plugin-usage.md) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue
- [Jira Server](jira-server-plugin-usage.md) - Allows you to create and link Unleash feature flags directly from a Jira Server issue
- [Microsoft Teams](teams.md) - Allows Unleash to post updates to Microsoft Teams.
-- [Slack](slack.md) - Allows Unleash to post updates to Slack.
+- [Slack App](slack-app.md) - The Unleash Slack App posts messages to the selected channels in your Slack workspace.
- [Webhook](webhook.md) - A generic way to post messages from Unleash to third party services.
:::tip Missing an integration? Request it!
@@ -33,6 +33,12 @@ If you're looking for an integration that Unleash doesn't have at the moment, yo
:::
+## Deprecated integrations
+
+These integrations are deprecated and will be removed in a future release:
+
+- [Slack](slack.md) - Allows Unleash to post updates to Slack. Please try the new [Slack App](slack-app.md) integration instead.
+
## Community integrations
Our wonderful community has also created the following integrations:
diff --git a/website/docs/reference/integrations/slack-app.md b/website/docs/reference/integrations/slack-app.md
new file mode 100644
index 0000000000..e83da6684d
--- /dev/null
+++ b/website/docs/reference/integrations/slack-app.md
@@ -0,0 +1,63 @@
+---
+title: Slack App
+---
+
+import Figure from '@site/src/components/Figure/Figure.tsx'
+
+:::info Availability
+
+The Slack App integration was introduced in **Unleash 5.5**.
+
+:::
+
+The Slack App integration posts messages to a specified set of channels in your Slack workspace. The channels can be public or private, and can be specified on a per-flag basis by using [Slack tags](#tags).
+
+## Installation {#installation}
+
+To install the Slack App integration, follow these steps:
+
+1. Navigate to the *integrations* page in the Unleash admin UI (available at the URL `/integrations`) and select "configure" on the Slack App integration.
+2. On the integration configuration form, use the "install & connect" button.
+3. A new tab will open, asking you to select the Slack workspace where you'd like to install the app.
+4. After successful installation of the Unleash Slack App in your chosen Slack workspace, you'll be automatically redirected to a page displaying a newly generated access token.
+5. Copy this access token and paste it into the `Access token` field within the integration settings.
+
+By default, the Unleash Slack App is granted access to public channels. If you want the app to post messages to private channels, you'll need to manually invite it to each of those channels.
+
+## Configuration {#configuration}
+
+The configuration settings allow you to choose the events you're interested in and whether you want to filter them by projects and environments. You can configure a comma-separated list of channels to post the configured events to. These channels are always notified, regardless of the event type or the presence of [Slack tags](#tags).
+
+#### Events {#events}
+
+You can choose to trigger updates for the following events:
+
+- feature-created
+- feature-metadata-updated
+- feature-project-change
+- feature-archived
+- feature-revived
+- feature-strategy-update
+- feature-strategy-add
+- feature-strategy-remove
+- feature-stale-on
+- feature-stale-off
+- feature-environment-enabled
+- feature-environment-disabled
+- feature-environment-variants-updated
+- feature-potentially-stale-on
+
+#### Parameters {#parameters}
+
+The Unleash Slack App integration takes the following parameters.
+
+- **Access token** - This is the only required property. After successful installation of the Unleash Slack App in your chosen Slack workspace, you'll be automatically redirected to a page displaying a newly generated access token. You should copy this access token and paste it into this field.
+- **Channels** - A comma-separated list of channels to post the configured events to. These channels are always notified, regardless of the event type or the presence of a Slack tag.
+
+## Tags {#tags}
+
+Besides the configured channels, you can choose to notify other channels by tagging your feature flags with Slack-specific tags. For instance, if you want the Unleash Slack App to send notifications to the `#general` channel, add a Slack-type tag with the value "general" (or "#general"; both will work) to your flag. This will ensure that any configured events related to that feature flag will notify the tagged channel in addition to any channels configured on the integration-level.
+
+To exclusively use tags for determining notification channels, you can leave the "channels" field blank in the integration configuration. Since you can have multiple configurations for the integration, you're free to mix and match settings to meet your precise needs. Before posting a message, all channels for that event, both configured and tagged, are combined and duplicates are removed.
+
+
diff --git a/website/docs/reference/integrations/slack.md b/website/docs/reference/integrations/slack.md
index 4e2aa4c511..86e0e9bd5b 100644
--- a/website/docs/reference/integrations/slack.md
+++ b/website/docs/reference/integrations/slack.md
@@ -1,8 +1,14 @@
---
id: slack
-title: Slack
+title: Slack (deprecated)
---
+:::caution Deprecation notice
+
+This Slack integration is deprecated and will be removed in a future release. We recommend using the new [Slack App](./slack-app.md) integration instead.
+
+:::
+
> This feature was introduced in _Unleash v3.11.0_.
The Slack integration allows Unleash to post Updates when a feature toggle is updated. To set up Slack, you need to configure an incoming Slack webhook URL. You can follow [Sending messages using Incoming Webhooks](https://api.slack.com/incoming-webhooks) on how to do that. You can also choose to [create a slack app for Unleash](https://api.slack.com/apps), which will provide you with additional functionality to control how Unleash communicates messages on your Slack workspace.
@@ -48,6 +54,6 @@ Unleash Slack integration takes the following parameters.
The Slack integration also defined the Tag type "slack". You may use this tag to override which Slack channel Unleash should post updates to for this feature toggle.
-
+
In the picture you can see we have defined two slack tags for the "new-payment-system" toggle. In this example Unleash will post updates to the **#notifications** and **#random** channel.
diff --git a/website/docs/topics/feature-flag-migration/business-case-feature-flag-migration.md b/website/docs/topics/feature-flag-migration/business-case-feature-flag-migration.md
new file mode 100644
index 0000000000..d03041754c
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/business-case-feature-flag-migration.md
@@ -0,0 +1,16 @@
+---
+title: Make the business case for feature flag migration
+---
+
+Once you have scoped your migration, you need to make a business case. Even the most well planned migrations take effort, meaning time, money, and energy dedicated to a project. If you don’t have the proper buy-in, you risk being under-resourced or worse, being unable to complete the migration at all.
+
+When building a business case, you want to be clear on what pain the feature flag migration is solving and the happy end state once the migration is complete.
+
+To structure your thinking, ask yourself:
+
+* What practices related to feature deployments, debugging and rollbacks are overburdening teams today and driving down productivity?
+* What specific deficiencies are there in the current platform
+* What business outcomes are you looking to drive?
+* After the migration, what does "better" look like?
+
+Use our [Feature Flag Migration template](https://docs.google.com/spreadsheets/d/1MKc95v7Tc-9tznWMDVSy2vvmVJTvOFLRVZpx1QrL-_U/edit#gid=996250264) to fill in details about your business case.
diff --git a/website/docs/topics/feature-flag-migration/feature-flag-migration-best-practices.md b/website/docs/topics/feature-flag-migration/feature-flag-migration-best-practices.md
new file mode 100644
index 0000000000..643922b62c
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/feature-flag-migration-best-practices.md
@@ -0,0 +1,17 @@
+---
+title: Best Practices for Migrating from a Homegrown Feature Management Solution
+---
+
+Many large organizations have an existing feature management solution that they have outgrown and plan to migrate to a feature flag service.
+
+This guide outlines Best Practices for feature flag migrations. Approaching the migration from your current feature flag solution to Unleash the right way will save you time, money, and a lot of headaches.
+
+Based on our work with organizations having millions of flags and thousands of users, there are five phases of a feature flag migration:
+
+1. [Defining the scope of the feature flag migration](./feature-flag-migration-scope.md)
+2. [Make the business case for feature flag migration](./business-case-feature-flag-migration.md)
+3. [Planning Feature Flag Migration](./planning-feature-flag-migration.md)
+4. [Migration Execution](./how-to-execute-feature-flag-migration.md)
+5. [Onboarding users](./onbording-users-to-feature-flag-service.md)
+
+This guide provides a summary of each topic as well as a detailed Feature Flag Migration template that you can use to plan your migration.
diff --git a/website/docs/topics/feature-flag-migration/feature-flag-migration-scope.md b/website/docs/topics/feature-flag-migration/feature-flag-migration-scope.md
new file mode 100644
index 0000000000..8bc7b6e198
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/feature-flag-migration-scope.md
@@ -0,0 +1,29 @@
+---
+title: Defining the scope of the feature flag migration
+---
+
+Scoping a feature flag migration properly is the most significant task you can do to ensure the success of your project.
+
+Based on experiences working with dozens of large enterprises migrating homegrown systems to Unleash, we recommend two best practices when scoping your feature flag migration.
+
+## 1- Separate the migration of old flags from the existing system from new flags created in Unleash.
+
+The older the system, the more existing flags there are. It might take weeks or months to hunt down the developer responsible for an old flag in an obscure part of the code base. In the meantime, hundreds of developers are trying to create new flags today. By separating these concerns, you can get to the "happy end state" for your development team faster, and burn down your flag migrations over time.
+
+So you should end up with two separate tracks as part of your project scope.
+
+1. Build the new platform around the "better" target state - ideal use cases and ways of working that enable greater levels of developer efficiency
+
+In parallel, the second track:
+
+2. Clean up stale feature flags in the current platform. You should decide strategically on what should be migrated and what should be cleaned up. Many old flags can simply be deleted rather than migrated.
+
+## 2- Do not make end-to-end app modernization a dependency of your feature flag migration
+
+Organizations who adopt feature flags see improvements in all key operational metrics for DevOps: Lead time to changes, mean-time-to-recovery, deployment frequency, and change failure rate. So it is natural as part of a feature flag migration to also improve other parts of the software development lifecycle. From the perspective of feature flag migration, this is a mistake.
+
+Making feature flag migration dependent on breaking down mission-critical monolithic applications into microservices, for example, will slow down your feature flag migration.
+
+Rather, enable feature flags for all codebases, independent of your state of modernization. Even monolithic applications can benefit from feature flags in some instances. When this monolith is broken down, the accrued benefits will be even greater, and you will ship your new feature management system a lot faster.
+
+Use our [Feature Flag Migration template](https://docs.google.com/spreadsheets/d/1MKc95v7Tc-9tznWMDVSy2vvmVJTvOFLRVZpx1QrL-_U/edit#gid=996250264) to fill in details about your project scope.
diff --git a/website/docs/topics/feature-flag-migration/how-to-execute-feature-flag-migration.md b/website/docs/topics/feature-flag-migration/how-to-execute-feature-flag-migration.md
new file mode 100644
index 0000000000..5430e1e37a
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/how-to-execute-feature-flag-migration.md
@@ -0,0 +1,31 @@
+---
+title: Migration Execution
+---
+
+Now that we have completed the planning, below are some of our Best Practices for carrying out the migration based on our experience.
+
+First, it can help to break the migration down into an order of activities, for example:
+
+* **Minimum Viable Product (MVP) launch**
+ * Platform implemented, passed security/change management requirements, and available for developer use
+ * Rollout to the highest priority groups of users
+ * Matching use cases of the legacy platform
+ * Legacy system fallback available
+* **Medium-term**
+ * Rollout to additional groups; adoption of further, less critical use cases
+ * Sunset of legacy system
+* **Longer term**
+ * Adoption of new use cases
+
+For each activity, plan for the Level of Effort (LoE), or the number of hours/days the task will take the assigned resource or group to fulfill.
+
+Next up is risk handling. **Are there any perceived risks to the timelines that could be addressed upfront?**
+
+* Have the teams involved with the migration committed to set hours for working the migration tasks upfront, have had migration project success criteria and their tasks communicated to them, and Q&A fulfilled?
+* How long are various sign-offs by any relevant groups expected to take?
+ * E.g. Change Advisory Board, Security Controls, hardening checks, etc
+ * Plan to exceed each team’s documentation requirements to ensure fewer Requests for Information
+
+Every step of the way, it can help to conduct reviews and look-backs at each rollout stage as well as what lies ahead.
+
+Use our [Feature Flag Migration template](https://docs.google.com/spreadsheets/d/1MKc95v7Tc-9tznWMDVSy2vvmVJTvOFLRVZpx1QrL-_U/edit#gid=996250264) to fill in details about your project plan execution.
diff --git a/website/docs/topics/feature-flag-migration/onbording-users-to-feature-flag-service.md b/website/docs/topics/feature-flag-migration/onbording-users-to-feature-flag-service.md
new file mode 100644
index 0000000000..f77c822fdf
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/onbording-users-to-feature-flag-service.md
@@ -0,0 +1,9 @@
+---
+title: Onboarding users
+---
+
+Finally, after the migration has been completed and everyone has celebrated, you need to onboard team members onto the platform.
+
+Unleash Customer Success is here to help, whether your developers are seasoned feature flag management experts or new to the concepts - we will deliver tailored, white-glove training to accommodate use cases and developer skill levels.
+
+In addition, for those who prefer a self-paced approach, a wealth of content is available on our [YouTube channel](https://www.youtube.com/channel/UCJjGVOc5QBbEje-r7nZEa4A), [website](https://www.getunleash.io/), and [documentation](https://docs.getunleash.io/) portal to get your teams going quickly.
diff --git a/website/docs/topics/feature-flag-migration/planning-feature-flag-migration.md b/website/docs/topics/feature-flag-migration/planning-feature-flag-migration.md
new file mode 100644
index 0000000000..7a4b904171
--- /dev/null
+++ b/website/docs/topics/feature-flag-migration/planning-feature-flag-migration.md
@@ -0,0 +1,86 @@
+---
+title: Planning Feature Flag Migration
+---
+
+When planning your feature flag migration, it is essential to focus on four key areas:
+
+* Use cases
+* Core feature flag setup
+* Key stakeholders
+* System architecture
+
+## Use Cases
+
+A key requirement is to understand how feature flags will be used so that you can set up the proper data model, user permissions, and system architecture.
+
+Below are some of the most common use cases for feature flags. Start by selecting those that are in scope for your initial rollout. It is common to start with some, but not all, of these and roll out the remaining in the future.
+
+Use cases for feature flags:
+
+* Operational or Permission flags (also known as "Kill Switches")
+* Gradual rollouts
+* Canary releases
+* A/B testing / Experimentation
+
+Core Feature Flag setup
+
+This planning phase is all about understanding the anatomy of the existing feature flag setup so it can be moved to Unleash.
+
+Key questions include:
+
+* Many many flags are there?
+* How many are active?
+* Do the inactive flags need to be migrated, or can they be removed entirely, simplifying migration?
+
+Once you have an understanding of what needs to be migrated, you should plan for how flags will be organized in the future. Picking the right organizing principle is critical for access controls. Unleash supports Application, Project, Environment, and Role-based access, so pick the option that makes the most logical sense for your organization.
+
+Our experience tells us that organizing flags by the development teams that work on them is the best approach. For example:
+
+* By application or microservice
+ * E.g. Shopping Cart, Website, Mobile app
+* By Projects
+ * E.g. Logistics, Finance
+* By organization hierarchy
+ * E.g. Frontend, backend, platform teams
+
+## Key stakeholders
+
+When planning your migration, it is important to understand who will be managing the feature flag system and who will be using the feature flag system on a day-to-day basis. Additionally, you need to know who will be responsible for key migration tasks.
+
+From our experience, looping all key stakeholders into the project early on means that all eventualities can be planned for in advance, reducing the risk of project implementation delays due to unforeseen sign-off requirements. Decision makers can help assign and gather resources needed for the migration, as well as advise on the correct business processes that need to be followed at the various project stages.
+
+System Architecture
+
+You will also need to plan how you set up Unleash itself as part of your migration planning process. Unleash is extremely flexible with lots of hosting and security configuration options to align with the unique requirements of large enterprises.
+
+
+## How is our current feature flag architecture set up?
+
+This part is key to understanding how Unleash needs to be implemented. This plays a part in resource planning for both personnel and infrastructure cost allocation. For instance
+
+* What languages and frameworks are our front end and backend using?
+* Where are our applications hosted?
+* Where are end users of the application based geographically?
+
+## Security and organizational policy requirements
+
+You will also want to pay attention to Security & Organisational Policy requirements.
+
+For example, do you need to keep sensitive context inside your firewall perimeter?
+
+Often the answer to this question defines whether you will run Unleash in a hosted, or self-hosted fashion.
+
+Many customers prefer a hosted solution if their security policy will allow it because it reduces overhead on SRE teams and infrastructure. Unleash offers a single-tenant hosted solution, so even security-conscious customers can sometimes opt for a hosted solution.
+
+If that is not an option, Unleash instances need to be managed by customer SRE / DevOps teams. If this is the direction you are going, you should plan for it in this phase of the project.
+
+Other areas of system architecture to investigate during the planning phase are:
+
+* Data protection
+ * Do we have to comply with HIPPA, SOC-2, ISO 27001, GDPR, etc?
+* How do we authenticate and manage user access & RBAC/roles?
+* Do we have any Change Management policies we need to adhere to?
+* Do we consume feature flag data, such as events, in any other systems downstream?
+ * For example, Jira Cloud for issue management, Datadog for real-time telemetry, Slack or Microsoft Teams for notifications or Google Analytics for user interactions.
+
+Use our [Feature Flag Migration template](https://docs.google.com/spreadsheets/d/1MKc95v7Tc-9tznWMDVSy2vvmVJTvOFLRVZpx1QrL-_U/edit#gid=996250264) to fill in details about your project planning.
diff --git a/website/docs/topics/feature-flags/availability-over-consistency.md b/website/docs/topics/feature-flags/availability-over-consistency.md
new file mode 100644
index 0000000000..4005db3158
--- /dev/null
+++ b/website/docs/topics/feature-flags/availability-over-consistency.md
@@ -0,0 +1,21 @@
+---
+title: 6. Design for failure. Favor availability over consistency.
+---
+
+Your feature flag system should not be able to take down your main application under any circumstance, including network disruptions. Follow these patterns to achieve fault tolerance for your feature flag system.
+
+**Zero dependencies**: Your application's availability should have zero dependencies on the availability of your feature flag system. Robust feature flag systems avoid relying on real-time flag evaluations because the unavailability of the feature flag system will cause application downtime, outages, degraded performance, or even a complete failure of your application.
+
+ **Graceful degradation**: If the system goes down, it should not disrupt the user experience or cause unexpected behavior. Feature flagging should gracefully degrade in the absence of the Feature Flag Control service, ensuring that users can continue to use the application without disruption.
+
+**Resilient Architecture Patterns**:
+
+ - **Bootstrapping SDKs with Data**: Feature flagging SDKs used within your application should be designed to work with locally cached data, even when the network connection to the Feature Flag Control service is unavailable. The SDKs can bootstrap with the last known feature flag configuration or default values to ensure uninterrupted functionality.
+
+ - **Local Cache**: Maintaining a local cache of feature flag configuration helps reduce network round trips and dependency on external services. The local cache can be periodically synchronized with the central Feature Flag Control service when it's available. This approach minimizes the impact of network failures or service downtime on your application.
+
+ - **Evaluate Locally**: Whenever possible, the SDKs or application components should be able to evaluate feature flags locally without relying on external services. This ensures that feature flag evaluations continue even when the feature flagging service is temporarily unavailable.
+
+ - **Availability Over Consistency**: As the CAP theorem teaches us, in distributed systems, prioritizing availability over strict consistency can be a crucial design choice. This means that, in the face of network partitions or downtime of external services, your application should favor maintaining its availability rather than enforcing perfectly consistent feature flag configuration caches. Eventually consistent systems can tolerate temporary inconsistencies in flag evaluations without compromising availability. In CAP theorem parlance, a feature flagging system should aim for AP over CP.
+
+By implementing these resilient architecture patterns, your feature flagging system can continue to function effectively even in the presence of downtime or network disruptions in the feature flagging service. This ensures that your main application remains stable, available, and resilient to potential issues in the feature flagging infrastructure, ultimately leading to a better user experience and improved reliability.
diff --git a/website/docs/topics/feature-flags/democratize-feature-flag-access.md b/website/docs/topics/feature-flags/democratize-feature-flag-access.md
new file mode 100644
index 0000000000..354fdb1e05
--- /dev/null
+++ b/website/docs/topics/feature-flags/democratize-feature-flag-access.md
@@ -0,0 +1,31 @@
+---
+title: 9. Choose open by default. Democratize feature flag access.
+---
+
+Allowing engineers, product owners, and even technical support to have open access to a feature flagging system is essential for effective development, debugging, and decision-making. These groups should have access to the system, along with access to the codebase and visibility into configuration changes:
+
+1. **Debugging and Issue Resolution**:
+
+ - **Code Access**: Engineers should have access to the codebase where feature flags are implemented. This access enables them to quickly diagnose and fix issues related to feature flags when they arise. Without code access, debugging becomes cumbersome, and troubleshooting becomes slower, potentially leading to extended downtimes or performance problems.
+
+2. **Visibility into Configuration**:
+
+ - **Configuration Transparency**: Engineers, product owners, and even technical support should be able to view the feature toggle configuration. This transparency provides insights into which features are currently active, what conditions trigger them, and how they impact the application's behavior. It helps understand the system's state and behavior, which is crucial for making informed decisions.
+
+ - **Change History**: Access to a history of changes made to feature flags, including who made the changes and when, is invaluable. This audit trail allows teams to track changes to the system's behavior over time. It aids in accountability and can be instrumental in troubleshooting when unexpected behavior arises after a change.
+
+ - **Correlating Changes with Metrics**: Engineers and product owners often need to correlate feature flag changes with production application metrics. This correlation helps them understand how feature flags affect user behavior, performance, and system health. It's essential for making data-driven decisions about feature rollouts, optimizations, or rollbacks.
+
+3. **Collaboration**:
+
+ - **Efficient Communication**: Open access fosters efficient communication between engineers and the rest of the organization. When it's open by default, everyone can see the feature flagging system and its changes, and have more productive discussions about feature releases, experiments, and their impact on the user experience.
+
+4. **Empowering Product Decisions**:
+
+ - **Product Owner Involvement**: Product owners play a critical role in defining feature flags' behavior and rollout strategies based on user needs and business goals. Allowing them to access the feature flagging system empowers them to make real-time decisions about feature releases, rollbacks, or adjustments without depending solely on engineering resources.
+
+5. **Security and Compliance**:
+
+ - **Security Audits**: Users of a feature flag system should be part of corporate access control groups such as SSO. Sometimes, additional controls are necessary, such as feature flag approvals using the four-eyes principle.
+
+Access control and visibility into feature flag changes are essential for security and compliance purposes. It helps track and audit who has made changes to the system, which can be crucial in maintaining data integrity and adhering to regulatory requirements.
diff --git a/website/docs/topics/feature-flags/enable-traceability.md b/website/docs/topics/feature-flags/enable-traceability.md
new file mode 100644
index 0000000000..44c7c71d40
--- /dev/null
+++ b/website/docs/topics/feature-flags/enable-traceability.md
@@ -0,0 +1,35 @@
+---
+title: 11. Enable traceability. Make it easy to understand flag evaluation.
+---
+
+Developer experience is a critical factor to consider when implementing a feature flag solution. A positive developer experience enhances the efficiency of the development process and contributes to the overall success and effectiveness of feature flagging. One crucial aspect of developer experience is ensuring the testability of the SDK and providing tools for developers to understand how and why feature flags are evaluated. This is important because:
+
+1. **Ease of Testing and Debugging:**
+
+ - **Faster Development Cycles:** A feature flagging solution with a testable SDK allows developers to quickly test and iterate on new features. They can easily turn flags on or off, simulate different conditions, and observe the results without needing extensive code changes or redeployments.
+
+ - **Rapid Issue Resolution:** When issues or unexpected behavior arise, a testable SDK enables developers to pinpoint the problem more efficiently. They can examine the flag configurations, log feature flag decisions, and troubleshoot issues more precisely.
+
+2. **Visibility into Flag Behaviour:**
+
+ - **Understanding User Experience:** Developers need tools to see and understand how feature flags affect the user experience. This visibility helps them gauge the impact of flag changes and make informed decisions about when to roll out features to different user segments. Debugging a feature flag with multiple inputs simultaneously makes it easy for developers to compare the results and quickly figure out how a feature flag evaluates in different scenarios with multiple input values.
+
+ - **Enhanced Collaboration:** Feature flagging often involves cross-functional teams, including developers, product managers, and QA testers. Providing tools with a clear view of flag behavior fosters effective collaboration and communication among team members.
+
+3. **Transparency and Confidence:**
+
+ - **Confidence in Flag Decisions:** A transparent feature flagging solution empowers developers to make data-driven decisions. They can see why a particular flag evaluates to a certain value, which is crucial for making informed choices about feature rollouts and experimentation.
+
+ - **Reduced Risk:** When developers clearly understand of why flags evaluate the way they do, they are less likely to make unintentional mistakes that could lead to unexpected issues in production.
+
+4. **Effective Monitoring and Metrics:**
+
+ - **Tracking Performance:** A testable SDK should provide developers with the ability to monitor the performance of feature flags in real time. This includes tracking metrics related to flag evaluations, user engagement, and the impact of flag changes.
+
+ - **Data-Driven Decisions:** Developers can use this data to evaluate the success of new features, conduct A/B tests, and make informed decisions about optimizations.
+
+ - **Usage metrics:** A feature flag system should provide insight on an aggregated level about the usage of feature flags. This is helpful for developers so that they can easily assess that everything works as expected.
+
+5. **Documentation and Training:**
+
+ - **Onboarding and Training:** The entire feature flag solution, including API, UI, and the SDKs, requires clear and comprehensive documentation, along with easy-to-understand examples, in order to simplify the onboarding process for new developers. It also supports the ongoing training of new team members, ensuring that everyone can effectively use the feature flagging solution.
diff --git a/website/docs/topics/feature-flags/evaluate-flags-close-to-user.md b/website/docs/topics/feature-flags/evaluate-flags-close-to-user.md
new file mode 100644
index 0000000000..c48b3b0251
--- /dev/null
+++ b/website/docs/topics/feature-flags/evaluate-flags-close-to-user.md
@@ -0,0 +1,25 @@
+---
+title: 3. Evaluate flags as close to the user as possible. Reduce latency.
+---
+
+Feature flags should be evaluated as close to your users as possible, and the evaluation should always happen server side as discussed in Principle 2. In addition to security and privacy benefits, performing evaluation as close as possible to your users has multiple benefits:
+
+1. **Performance Efficiency**:
+
+ a. **Reduced Latency**: Network roundtrips introduce latency, which can slow down your application's response time. Local evaluation eliminates the need for these roundtrips, resulting in faster feature flag decisions. Users will experience a more responsive application, which can be critical for maintaining a positive user experience.
+
+ b. **Offline Functionality**: Applications often need to function offline or in low-connectivity environments. Local evaluation ensures that feature flags can still be used and decisions can be made without relying on a network connection. This is especially important for mobile apps or services in remote locations.
+
+2. **Cost Savings**:
+
+ a. **Reduced Bandwidth Costs**: Local evaluation reduces the amount of data transferred between your application and the feature flag service. This can lead to significant cost savings, particularly if you have a large user base or high traffic volume.
+
+3. **Offline Development and Testing**:
+
+ a. **Development and Testing**: Local evaluation is crucial for local development and testing environments where a network connection to the feature flag service might not be readily available. Developers can work on feature flag-related code without needing constant access to the service, streamlining the development process.
+
+4. **Resilience**:
+
+ a. **Service Outages**: If the feature flag service experiences downtime or outages, local evaluation allows your application to continue functioning without interruptions. This is important for maintaining service reliability and ensuring your application remains available even when the service is down.
+
+In summary, this principle emphasizes the importance of optimizing performance while protecting end-user privacy by evaluating feature flags as close to the end user as possible. Done right, this also leads to a highly available feature flag system that scales with your applications.
diff --git a/website/docs/topics/feature-flags/feature-flag-best-practices.md b/website/docs/topics/feature-flags/feature-flag-best-practices.md
new file mode 100644
index 0000000000..a3c88473e4
--- /dev/null
+++ b/website/docs/topics/feature-flags/feature-flag-best-practices.md
@@ -0,0 +1,35 @@
+---
+title: 11 Principles for building and scaling feature flag systems
+---
+
+Feature flags, sometimes called feature toggles or feature switches, are a software development technique that allows engineering teams to decouple the release of new functionality from software deployments. With feature flags, developers can turn specific features or code segments on or off at runtime, without the need for a code deployment or rollback. Organizations who adopt feature flags see improvements in all key operational metrics for DevOps: Lead time to changes, mean-time-to-recovery, deployment frequency, and change failure rate.
+
+There are 11 principles for building a large-scale feature flag system. These principles have their roots in distributed systems architecture and pay particular attention to security, privacy, and scale that is required by most enterprise systems. If you follow these principles, your feature flag system is less likely to break under load and will be easier to evolve and maintain.
+
+These principles are:
+
+1. [Enable run-time control. Control flags dynamically, not using config files.](./runtime-control.md)
+2. [Never expose PII. Follow the principle of least privilege.](./never-expose-pii.md)
+3. [Evaluate flags as close to the user as possible. Reduce latency.](./evaluate-flags-close-to-user.md)
+4. [Scale Horizontally. Decouple reading and writing flags.](./scale-horizontally.md)
+5. [Limit payloads. Feature flag payload should be as small as possible.](./limit-payloads.md)
+6. [Design for failure. Favor availability over consistency.](./availability-over-consistency.md)
+7. [Make feature flags short-lived. Do not confuse flags with application configuration.](./short-lived-feature-flags.md)
+8. [Use unique names across all applications. Enforce naming conventions.](./unique-names.md)
+9. [Choose open by default. Democratize feature flag access.](./democratize-feature-flag-access.md)
+10. [Do no harm. Prioritize consistent user experience.](./prioritize-ux.md)
+11. [Enable traceability. Make it easy to understand flag evaluation](./enable-traceability.md)
+
+## Background
+
+Feature flags have become a central part of the DevOps toolbox along with Git, CI/CD and microservices. You can write modern software without all of these things, but it sure is a lot harder, and a lot less fun.
+
+And just like the wrong Git repo design can cause interminable headaches, getting the details wrong when first building a feature flag system can be very costly.
+
+This set of principles for building a large-scale feature management platform is the result of thousands of hours of work building and scaling Unleash, an open-source feature management solution used by thousands of organizations.
+
+Before Unleash was a community and a company, it was an internal project, started by [one dev](https://github.com/ivarconr), for one company. As the community behind Unleash grew, patterns and anti-patterns of large-scale feature flag systems emerged. Our community quickly discovered that these are important principles for anyone who wanted to avoid spending weekends debugging the production system that is supposed to make debugging in production easier.
+
+“Large scale” means the ability to support millions of flags served to end-users with minimal latency or impact on application uptime or performance. That is the type of system most large enterprises are building today and the type of feature flag system that this guide focuses on.
+
+Our motivation for writing these principles is to share what we’ve learned building a large-scale feature flag solution with other architects and engineers solving similar challenges. Unleash is open-source, and so are these principles. Have something to contribute? [Open a PR](https://github.com/Unleash/unleash/pulls) or [discussion](https://github.com/orgs/Unleash/discussions) on our Github.
diff --git a/website/docs/topics/feature-flags/limit-payloads.md b/website/docs/topics/feature-flags/limit-payloads.md
new file mode 100644
index 0000000000..e45b966b9e
--- /dev/null
+++ b/website/docs/topics/feature-flags/limit-payloads.md
@@ -0,0 +1,38 @@
+---
+title: 5. Limit payloads. Feature flag payload should be as small as possible.
+---
+
+Minimizing the size of feature flag payloads is a critical aspect of maintaining the efficiency and performance of a feature flag system. The configuration of your feature flags can vary in size depending on the complexity of your targeting rules. For instance, if you have a targeting engine that determines whether a feature flag should be active or inactive based on individual user IDs, you might be tempted to include all these user IDs within the configuration payload. While this approach may work fine for a small user base, it can become unwieldy when dealing with a large number of users.
+
+If you find yourself facing this challenge, your instinct might be to store this extensive user information directly in the feature flagging system. However, this can also run into scaling problems. A more efficient approach is to categorize these users into logical groupings at a different layer and then use these group identifiers when you evaluate flags within your feature flagging system. For example, you can group users based on their subscription plan or geographical location. Find a suitable parameter for grouping users, and employ those group parameters as targeting rules in your feature flagging solution.
+
+Imposing limitations on payloads is crucial for scaling a feature flag system:
+
+1. **Reduced Network Load**:
+
+ - Large payloads, especially for feature flag evaluations, can lead to increased network traffic between the application and the feature flagging service. This can overwhelm the network and cause bottlenecks, leading to slow response times and degraded system performance. Limiting payloads helps reduce the amount of data transferred over the network, alleviating this burden. Even small numbers become large when multiplied by millions.
+
+2. **Faster Evaluation**:
+
+ - Smaller payloads reduce latency which means quicker transmission and evaluation. Speed is essential when evaluating feature flags, especially for real-time decisions that impact user experiences. Limiting payloads ensures evaluations occur faster, allowing your application to respond promptly to feature flag changes.
+
+3. **Improved Memory Efficiency**:
+
+ - Feature flagging systems often store flag configurations in memory for quick access during runtime. Larger payloads consume more memory, potentially causing memory exhaustion and system crashes. By limiting payloads, you ensure that the system remains memory-efficient, reducing the risk of resource-related issues.
+
+4. **Scalability**:
+
+ - Scalability is a critical concern for modern applications, especially those experiencing rapid growth. Feature flagging solutions need to scale horizontally to accommodate increased workloads. Smaller payloads require fewer resources for processing, making it easier to scale your system horizontally.
+
+5. **Lower Infrastructure Costs**:
+
+ - When payloads are limited, the infrastructure required to support the feature flagging system can be smaller and less costly. This saves on infrastructure expenses and simplifies the management and maintenance of the system.
+
+
+6. **Reliability**:
+
+ - A feature flagging system that consistently delivers small, manageable payloads is more likely to be reliable. It reduces the risk of network failures, timeouts, and other issues when handling large data transfers. Reliability is paramount for mission-critical applications.
+
+7. **Ease of Monitoring and Debugging**:
+
+ - Smaller payloads are easier to monitor and debug. When issues arise, it's simpler to trace problems and identify their root causes when dealing with smaller, more manageable data sets.
diff --git a/website/docs/topics/feature-flags/never-expose-pii.md b/website/docs/topics/feature-flags/never-expose-pii.md
new file mode 100644
index 0000000000..d16e5791aa
--- /dev/null
+++ b/website/docs/topics/feature-flags/never-expose-pii.md
@@ -0,0 +1,39 @@
+---
+title: 2. Never expose PII. Follow the principle of least privilege.
+---
+
+To keep things simple, you may be tempted to evaluate the feature flags in your Feature Flag Control Service. Don’t. Your Feature Flag Control Service should only handle the configuration for your feature flags and pass this configuration down to SDKs connecting from your applications.
+
+The primary rationale behind this practice is that feature flags often require contextual data for accurate evaluation. This may include user IDs, email addresses, or geographical locations that influence whether a flag should be toggled on or off. Safeguarding this sensitive information from external exposure is paramount. This information may include Personally Identifiable Information (PII), which must remain confined within the boundaries of your application, following the data security principle of least privilege (PoLP).
+
+
+
+For client-side applications where the code resides on the user's machine, such as in the browser or on mobile devices, you’ll want to take a different approach. You can’t evaluate on the client side because it raises significant security concerns by exposing potentially sensitive information such as API keys, flag data, and flag configurations. Placing these critical elements on the client side increases the risk of unauthorized access, tampering, or data breaches.
+
+Instead of performing client-side evaluation, a more secure and maintainable approach is to conduct feature flag evaluation within a self-hosted environment. Doing so can safeguard sensitive elements like API keys and flag configurations from potential client-side exposure. This strategy involves a server-side evaluation of feature flags, where the server makes decisions based on user and application parameters and then securely passes down the evaluated results to the frontend without any configuration leaking.
+
+
+
+Here’s how you can architect your solution to minimize PII or configuration leakage:
+
+1. **Server-Side Components**:
+
+In Principle 1, we proposed a set of architectural principles and components to set up a Feature Flag Control Service. The same architecture patterns apply here, with additional suggestions for achieving local evaluation. Refer to Principle 1 for patterns to set up a feature flagging service.
+
+**Feature Flag Evaluation Service**: If you need to use feature flags on the client side, where code is delivered to users' devices, you’ll need an evaluation server that can evaluate feature flags and pass evaluated results down to the SDK in the client application.
+
+2. **SDKs**:
+
+SDKs will make it more comfortable to work with feature flags. Depending on the context of your infrastructure, you need different types of SDKs to talk to your feature flagging service. For the server side, you’ll need SDKs that can talk directly to the feature flagging service and fetch the configuration.
+
+The server-side SDKs should implement logic to evaluate feature flags based on the configuration received from the Feature Flag Control Service and the application-specific context. Local evaluation ensures that decisions are made quickly without relying on network roundtrips.
+
+For client-side feature flags, you’ll need a different type of SDK. These SDKs will send the context to the Feature Flag Evaluation Service and receive the evaluated results. These results should be stored in memory and used when doing a feature flag lookup in the client-side application. By keeping the evaluated results for a specific context in memory in the client-side application, you avoid network roundtrips every time your application needs to check the status of a feature flag. It achieves the same level of performance as a server-side SDK, but the content stored in memory is different and limited to evaluated results on the client.
+
+The benefits of this approach include:
+
+ **Privacy Protection**:
+
+ a. **Data Minimization**: By evaluating feature flags in this way, you minimize the amount of data that needs to be sent to the Feature Flag Control Service. This can be crucial for protecting user privacy, as less user-specific data is transmitted over the network.
+
+ b. **Reduced Data Exposure**: Sensitive information about your users or application's behavior is less likely to be exposed to potential security threats. Data breaches or leaks can be mitigated by limiting the transmission of sensitive data.
diff --git a/website/docs/topics/feature-flags/prioritize-ux.md b/website/docs/topics/feature-flags/prioritize-ux.md
new file mode 100644
index 0000000000..5e8ce855fa
--- /dev/null
+++ b/website/docs/topics/feature-flags/prioritize-ux.md
@@ -0,0 +1,31 @@
+---
+title: 10. Do no harm. Prioritize consistent user experience.
+---
+
+Feature flagging solutions are indispensable tools in modern software development, enabling teams to manage feature releases and experiment with new functionality. However, one aspect that is absolutely non-negotiable in any feature flag solution is the need to ensure a consistent user experience. This isn't a luxury; it's a fundamental requirement. Feature flagging solutions must prioritize consistency and guarantee the same user experience every time, especially with percentage-based gradual rollouts.
+
+**Why Consistency is Paramount:**
+
+1. **User Trust**: Consistency breeds trust. When users interact with an application, they form expectations about how it behaves. Any sudden deviations can erode trust and lead to a sense of unreliability.
+
+2. **Reduced Friction**: Consistency reduces friction. Users shouldn't have to relearn how to use an app every time they open it. A consistent experience reduces the cognitive load on users, enabling them to engage effortlessly.
+
+3. **Quality Assurance**: Maintaining a consistent experience makes quality assurance more manageable. It's easier to test and monitor when you have a reliable benchmark for the user experience.
+
+4. **Support and Feedback**: Inconsistent experiences lead to confused users, increased support requests, and muddied user feedback. Consistency ensures that user issues are easier to identify and address.
+
+5. **Brand Integrity**: A consistent experience reflects positively on your brand. It demonstrates professionalism and commitment to user satisfaction, enhancing your brand's reputation.
+
+**Strategies for Consistency in Percentage-Based Gradual Rollouts:**
+
+1. **User Hashing**: Assign users to consistent groups using a secure hashing algorithm based on unique identifiers like user IDs or emails. This ensures that the same user consistently falls into the same group.
+
+2. **Segmentation Control**: Provide controls within the feature flagging tool to allow developers to segment users logically. For instance, segment by location, subscription type, or any relevant criteria to ensure similar user experiences.
+
+3. **Fallback Mechanisms**: Include fallback mechanisms in your architecture. If a user encounters issues or inconsistencies, the system can automatically switch them to a stable version or feature state.
+
+4. **Logging and Monitoring**: Implement robust logging and monitoring. Continuously track which users are in which groups and what version of the feature they are experiencing. Monitor for anomalies or deviations and consider building automated processes to disable features that may be misbehaving.
+
+5. **Transparent Communication**: Clearly communicate the gradual rollout to users. Use in-app notifications, tooltips, or changelogs to inform users about changes, ensuring they know what to expect.
+
+In summary, consistency is a cornerstone of effective feature flagging solutions. When designing an architecture for percentage-based gradual rollouts, prioritize mechanisms that guarantee the same user gets the same experience every time. This isn't just about good software practice; it's about respecting your users and upholding their trust in your application. By implementing these strategies, you can create a feature flagging solution that empowers your development process and delights your users with a dependable and consistent experience.
diff --git a/website/docs/topics/feature-flags/runtime-control.md b/website/docs/topics/feature-flags/runtime-control.md
new file mode 100644
index 0000000000..e95747a81c
--- /dev/null
+++ b/website/docs/topics/feature-flags/runtime-control.md
@@ -0,0 +1,23 @@
+---
+title: 1. Enable run-time control. Control flags dynamically, not using config files.
+---
+
+A scalable feature management system evaluates flags at runtime. Flags are dynamic, not static. If you need to restart your application to turn on a flag, you are using configuration, not feature flags.
+
+A large-scale feature flag system that enables runtime control should have at minimum the following components:
+
+**1. Feature Flag Control Service**: Use a centralized feature flag service that acts as the control plane for your feature flags. This service will handle flag configuration. The scope of this service should reflect the boundaries of your organization.
+
+Independent business units or product lines should potentially have their own instances, while business units or product lines that work closely together should most likely use the same instance in order to facilitate collaboration. This will always be a contextual decision based on your organization and how you organize the work, but keep in mind that you’d like to keep the management of the flags as simple as possible to avoid the complexity of cross-instance synchronization of feature flag configuration.
+
+**2. Database or Data Store**: Use a robust and scalable database or data store to store feature flag configurations. Popular choices include SQL or NoSQL databases or key-value stores. Ensure that this store is highly available and reliable.
+
+**3. API Layer**: Develop an API layer that exposes endpoints for your application to interact with the Feature Flag Control Service. This API should allow your application to request feature flag configurations.
+
+**4. Feature Flag SDK**: Build or integrate a feature flag SDK into your application. This SDK should provide an easy-to-use interface for fetching flag configurations and evaluating feature flags at runtime. When evaluating feature flags in your application, the call to the SDK should query the local cache, and the SDK should ask the central service for updates in the background.
+
+Build SDK bindings for each relevant language in your organization. Make sure that the SDKs uphold a standard contract governed by a set of feature flag client specifications that documents what functionality each SDK should support.
+
+
+
+**5. Continuously Updated**: Implement update mechanisms in your application so that changes to feature flag configurations are reflected without requiring application restarts or redeployments. The SDK should handle subscriptions or polling to the feature flag service for updates.
diff --git a/website/docs/topics/feature-flags/scale-horizontally.md b/website/docs/topics/feature-flags/scale-horizontally.md
new file mode 100644
index 0000000000..7262f2dde8
--- /dev/null
+++ b/website/docs/topics/feature-flags/scale-horizontally.md
@@ -0,0 +1,31 @@
+---
+title: 4. Scale Horizontally. Decouple reading and writing flags.
+---
+
+Separating the reading and writing of feature flags into distinct APIs is a critical architectural decision for building a scalable and efficient feature flag system, particularly when considering horizontal scaling. This separation provides several benefits:
+
+
+
+1. **Horizontal Scaling**:
+
+ - By separating read and write APIs, you can horizontally scale each component independently. This enables you to add more servers or containers to handle increased traffic for reading feature flags, writing updates, or both, depending on the demand.
+
+2. **Caching Efficiency**:
+
+ - Feature flag systems often rely on caching to improve response times for flag evaluations. Separating read and write APIs allows you to optimize caching strategies independently. For example, you can cache read operations more aggressively to minimize latency during flag evaluations while still ensuring that write operations maintain consistency across the system.
+
+3. **Granular Access Control**:
+
+ - Separation of read and write APIs simplifies access control and permissions management. You can apply different security measures and access controls to the two APIs. This helps ensure that only authorized users or systems can modify feature flags, reducing the risk of accidental or unauthorized changes.
+
+4. **Better Monitoring and Troubleshooting**:
+
+ - Monitoring and troubleshooting become more straightforward when read and write operations are separated. It's easier to track and analyze the performance of each API independently. When issues arise, you can isolate the source of the problem more quickly and apply targeted fixes or optimizations.
+
+5. **Flexibility and Maintenance**:
+
+ - Separation of concerns makes your system more flexible and maintainable. Changes or updates to one API won't directly impact the other, reducing the risk of unintended consequences. This separation allows development teams to work on each API separately, facilitating parallel development and deployment cycles.
+
+6. **Load Balancing**:
+
+ - Load balancing strategies can be tailored to the specific needs of the read and write APIs. You can distribute traffic and resources accordingly to optimize performance and ensure that neither API becomes a bottleneck under heavy loads.
diff --git a/website/docs/topics/feature-flags/short-lived-feature-flags.md b/website/docs/topics/feature-flags/short-lived-feature-flags.md
new file mode 100644
index 0000000000..ea0ee43a37
--- /dev/null
+++ b/website/docs/topics/feature-flags/short-lived-feature-flags.md
@@ -0,0 +1,20 @@
+---
+title: 7. Make feature flags short-lived. Do not confuse flags with application configuration.
+---
+
+Feature flags have a lifecycle shorter than an application lifecycle. The most common use case for feature flags is to protect new functionality. That means that when the roll-out of new functionality is complete, the feature flag should be removed from the code and archived. If there were old code paths that the new functionality replaces, those should also be cleaned up and removed.
+
+Feature flags should not be used for static application configuration. Application configuration is expected to be consistent, long-lived, and read when launching an application. Using feature flags to configure an application can lead to inconsistencies between different instances of the same application. Feature flags, on the other hand, are designed to be short-lived, dynamic, and changed at runtime. They are expected to be read and updated at runtime and favor availability over consistency.
+
+To succeed with feature flags in a large organization, you should:
+
+ - **Use flag expiration dates**: By setting expiration dates for your feature flags, you make it easier to keep track of old feature flags that are no longer needed. A proper feature flag solution will inform you about potentially expired flags.
+
+ - **Treat feature flags like technical debt.**: You must plan to clean up old feature branches in sprint or project planning, the same way you plan to clean up technical debt in your code. Feature flags add complexity to your code. You’ll need to know what code paths the feature flag enables, and while the feature flag lives, the context of it needs to be maintained and known within the organization. If you don’t clean up feature flags, eventually, you may lose the context surrounding it if enough time passes and/or personnel changes happen. As time passes, you will find it hard to remove flags, or to operate them effectively.
+
+- **Archive old flags**: Feature flags that are no longer in use should be archived after their usage has been removed from the codebase. The archive serves as an important audit log of feature flags that are no longer in use, and allows you to revive them if you need to install an older version of your application.
+
+There are valid exceptions to short-lived feature flags. In general, you should try to limit the amount of long-lived feature flags. Some examples include:
+
+* Kill-switches - these work like an inverted feature flag and are used to gracefully disable part of a system with known weak spots.
+* Internal flags used to enable additional debugging, tracing, and metrics at runtime, which are too costly to run all the time. These can be enabled by software engineers while debugging issues.
diff --git a/website/docs/topics/feature-flags/unique-names.md b/website/docs/topics/feature-flags/unique-names.md
new file mode 100644
index 0000000000..36dcd9fdfe
--- /dev/null
+++ b/website/docs/topics/feature-flags/unique-names.md
@@ -0,0 +1,15 @@
+---
+title: 8. Use unique names across all applications. Enforce naming conventions.
+---
+
+All flags served by the same Feature Flag Control service should have unique names across the entire cluster to avoid inconsistencies and errors.
+
+* **Avoid zombies:** Uniqueness should be controlled using a global list of feature flag names. This prevents the reuse of old flag names to protect new features. Using old names can lead to accidental exposure of old features, still protected with the same feature flag name.
+* **Naming convention enforcement: **Ideally, unique names are enforced at creation time. In a large organization, it is impossible for all developers to know all flags used. Enforcing a naming convention makes naming easier, ensures consistency, and provides an easy way to check for uniqueness.
+
+Unique naming has the following advantages:
+
+* **Flexibility over time: **Large enterprise systems are not static. Over time, monoliths are split into microservices, microservices are merged into larger microservices, and applications change responsibility. This means that the way flags are grouped will change over time, and a unique name for the entire organization ensures that you keep the option to reorganize your flags to match the changing needs of your organization.
+* **Prevent conflicts**: If two applications use the same Feature Flag name it can be impossible to know which flag is controlling which applications. This can lead to accidentally flipping the wrong flag, even if they are separated into different namespaces (projects, workspaces etc).
+* **Easier to manage: **It's easier to know what a flag is used for and where it is being used when it has a unique name. E.g. It will be easier to search across multiple code bases to find references for a feature flag when it has a unique identifier across the entire organization.
+* **Enables collaboration:** When a feature flag has a unique name in the organization, it simplifies collaboration across teams, products and applications. It ensures that we all talk about the same feature.
diff --git a/website/sidebars.js b/website/sidebars.js
index 3a38a2c21f..5795144fa6 100644
--- a/website/sidebars.js
+++ b/website/sidebars.js
@@ -28,7 +28,7 @@ module.exports = {
'tutorials/quickstart',
],
},
- {
+ {
label: 'Topic guides',
collapsed: false,
type: 'category',
@@ -36,15 +36,51 @@ module.exports = {
type: 'generated-index',
title: 'Topic guides',
description:
- 'Discussions, explanations, and explorations regarding topics related to Unleash.',
+ 'Discussions, explanations, and explorations regarding topics related to feature flags and Unleash.',
slug: '/topics',
},
items: [
+ {
+ type: 'category',
+ label: '11 Principles for building and scaling feature flag systems',
+ link: {
+ type: 'doc',
+ id: 'topics/feature-flags/feature-flag-best-practices',
+ },
+ items: [
+ 'topics/feature-flags/runtime-control',
+ 'topics/feature-flags/never-expose-pii',
+ 'topics/feature-flags/evaluate-flags-close-to-user',
+ 'topics/feature-flags/scale-horizontally',
+ 'topics/feature-flags/limit-payloads',
+ 'topics/feature-flags/availability-over-consistency',
+ 'topics/feature-flags/short-lived-feature-flags',
+ 'topics/feature-flags/unique-names',
+ 'topics/feature-flags/democratize-feature-flag-access',
+ 'topics/feature-flags/prioritize-ux',
+ 'topics/feature-flags/enable-traceability',
+ ],
+ },
'topics/the-anatomy-of-unleash',
'topics/a-b-testing',
+ {
+ type: 'category',
+ label: 'Feature Flag Migrations',
+ link: {
+ type: 'doc',
+ id: 'topics/feature-flag-migration/feature-flag-migration-best-practices',
+ },
+ items: [
+ 'topics/feature-flag-migration/feature-flag-migration-scope',
+ 'topics/feature-flag-migration/business-case-feature-flag-migration',
+ 'topics/feature-flag-migration/planning-feature-flag-migration',
+ 'topics/feature-flag-migration/how-to-execute-feature-flag-migration',
+ 'topics/feature-flag-migration/onbording-users-to-feature-flag-service',
+ ],
+ },
+ 'topics/data-collection',
'topics/managing-constraints',
'topics/proxy-hosting',
- 'topics/data-collection',
],
},
{
@@ -311,6 +347,7 @@ module.exports = {
'reference/integrations/jira-cloud-plugin-usage',
],
},
+ 'reference/integrations/slack-app',
'reference/integrations/slack',
'reference/integrations/teams',
'reference/integrations/webhook',
diff --git a/website/static/img/slack_addon_tags.png b/website/static/img/slack-addon-tags.png
similarity index 100%
rename from website/static/img/slack_addon_tags.png
rename to website/static/img/slack-addon-tags.png
diff --git a/yarn.lock b/yarn.lock
index 7e2f50ea8f..eb50f67156 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -1165,73 +1165,73 @@
p-queue "^6.6.1"
p-retry "^4.0.0"
-"@swc/core-darwin-arm64@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-darwin-arm64/-/core-darwin-arm64-1.3.84.tgz#9296626f9377e9bf92e41f9fe60a7cdc8c660e99"
- integrity sha512-mqK0buOo+toF2HoJ/gWj2ApZbvbIiNq3mMwSTHCYJHlQFQfoTWnl9aaD5GSO4wfNFVYfEZ1R259o5uv5NlVtoA==
+"@swc/core-darwin-arm64@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-darwin-arm64/-/core-darwin-arm64-1.3.83.tgz#eaeafce9bc9b8fce7d7c3d872b160b7660db8149"
+ integrity sha512-Plz2IKeveVLivbXTSCC3OZjD2MojyKYllhPrn9RotkDIZEFRYJZtW5/Ik1tJW/2rzu5HVKuGYrDKdScVVTbOxQ==
-"@swc/core-darwin-x64@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-darwin-x64/-/core-darwin-x64-1.3.84.tgz#60db6d6f512efd250e3a40cb80cec3d0b629f0a9"
- integrity sha512-cyuQZz62C43EDZqtnptUTlfDvAjgG3qu139m5zsfIK6ltXA5inKFbDWV3a/M5c18dFzA2Xh21Q46XZezmtQ9Tg==
+"@swc/core-darwin-x64@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-darwin-x64/-/core-darwin-x64-1.3.83.tgz#45c2d73843e5e2e34e6e9b8e5fd6e19b419b75ae"
+ integrity sha512-FBGVg5IPF/8jQ6FbK60iDUHjv0H5+LwfpJHKH6wZnRaYWFtm7+pzYgreLu3NTsm3m7/1a7t0+7KURwBGUaJCCw==
-"@swc/core-linux-arm-gnueabihf@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-linux-arm-gnueabihf/-/core-linux-arm-gnueabihf-1.3.84.tgz#eaf2f69c7be455184434a5b76ce07034bc43282a"
- integrity sha512-dmt/ECQrp3ZPWnK27p4E4xRIRHOoJhgGvxC5t5YaWzN20KcxE9ykEY2oLGSoeceM/A+4D11aRYGwF/EM7yOkvA==
+"@swc/core-linux-arm-gnueabihf@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-linux-arm-gnueabihf/-/core-linux-arm-gnueabihf-1.3.83.tgz#3dcee525f6667dd92db0640991a3f03764b76dea"
+ integrity sha512-EZcsuRYhGkzofXtzwDjuuBC/suiX9s7zeg2YYXOVjWwyebb6BUhB1yad3mcykFQ20rTLO9JUyIaiaMYDHGobqw==
-"@swc/core-linux-arm64-gnu@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-linux-arm64-gnu/-/core-linux-arm64-gnu-1.3.84.tgz#4c8236e1f90e1f8b74322ad73d20ce755db8f30a"
- integrity sha512-PgVfrI3NVg2z/oeg3GWLb9rFLMqidbdPwVH5nRyHVP2RX/BWP6qfnYfG+gJv4qrKzIldb9TyCGH7y8VWctKLxw==
+"@swc/core-linux-arm64-gnu@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-linux-arm64-gnu/-/core-linux-arm64-gnu-1.3.83.tgz#3521c8b2f05a5d0348e538af3a5742d607ad6a8d"
+ integrity sha512-khI41szLHrCD/cFOcN4p2SYvZgHjhhHlcMHz5BksRrDyteSJKu0qtWRZITVom0N/9jWoAleoFhMnFTUs0H8IWA==
-"@swc/core-linux-arm64-musl@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-linux-arm64-musl/-/core-linux-arm64-musl-1.3.84.tgz#f908c79bf5be14705e63ff44bea9216b128b492e"
- integrity sha512-hcuEa8/vin4Ns0P+FpcDHQ4f3jmhgGKQhqw0w+TovPSVTIXr+nrFQ2AGhs9nAxS6tSQ77C53Eb5YRpK8ToFo1A==
+"@swc/core-linux-arm64-musl@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-linux-arm64-musl/-/core-linux-arm64-musl-1.3.83.tgz#2c16d47e036176591761187455d4c2c4d984c14c"
+ integrity sha512-zgT7yNOdbjHcGAwvys79mbfNLK65KBlPJWzeig+Yk7I8TVzmaQge7B6ZS/gwF9/p+8TiLYo/tZ5aF2lqlgdSVw==
-"@swc/core-linux-x64-gnu@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-linux-x64-gnu/-/core-linux-x64-gnu-1.3.84.tgz#e7e4e94741547b81f9074d1b81b7ed42baec8660"
- integrity sha512-IvyimSbwGdu21jBBEqR1Up8Jhvl8kIAf1k3e5Oy8oRfgojdUfmW1EIwgGdoUeyQ1VHlfquiWaRGfsnHQUKl35g==
+"@swc/core-linux-x64-gnu@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-linux-x64-gnu/-/core-linux-x64-gnu-1.3.83.tgz#2eb0222eafeb247b9d1715f106e312566160bca1"
+ integrity sha512-x+mH0Y3NC/G0YNlFmGi3vGD4VOm7IPDhh+tGrx6WtJp0BsShAbOpxtfU885rp1QweZe4qYoEmGqiEjE2WrPIdA==
-"@swc/core-linux-x64-musl@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-linux-x64-musl/-/core-linux-x64-musl-1.3.84.tgz#34b6d275241692095f88940f675b53a880119920"
- integrity sha512-hdgVU/O5ufDCe+p5RtCjU7PRNwd0WM+eWJS+GNY4QWL6O8y2VLM+i4+6YzwSUjeBk0xd+1YElMxbqz7r5tSZhw==
+"@swc/core-linux-x64-musl@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-linux-x64-musl/-/core-linux-x64-musl-1.3.83.tgz#8c4edd4754410cfe662a112a92f0c71d4fbf070a"
+ integrity sha512-s5AYhAOmetUwUZwS5g9qb92IYgNHHBGiY2mTLImtEgpAeBwe0LPDj6WrujxCBuZnaS55mKRLLOuiMZE5TpjBNA==
-"@swc/core-win32-arm64-msvc@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-win32-arm64-msvc/-/core-win32-arm64-msvc-1.3.84.tgz#6be044ecc155e0695d51aa22df3e35caa2d91bd7"
- integrity sha512-rzH6k2BF0BFOFhUTD+bh0oCiUCZjFfDfoZoYNN/CM0qbtjAcFH21hzMh/EH8ZaXq8k/iQmUNNa5MPNPZ4SOMNw==
+"@swc/core-win32-arm64-msvc@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-win32-arm64-msvc/-/core-win32-arm64-msvc-1.3.83.tgz#153ef6fc6e41e33a47f9f1524fe6bad2fc0158b3"
+ integrity sha512-yw2rd/KVOGs95lRRB+killLWNaO1dy4uVa8Q3/4wb5txlLru07W1m041fZLzwOg/1Sh0TMjJgGxj0XHGR3ZXhQ==
-"@swc/core-win32-ia32-msvc@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-win32-ia32-msvc/-/core-win32-ia32-msvc-1.3.84.tgz#be357598bb03cb4470ffa158e0e86e47daa29f70"
- integrity sha512-Y+Dk7VLLVwwsAzoDmjkNW/sTmSPl9PGr4Mj1nhc5A2NNxZ+hz4SxFMclacDI03SC5ikK8Qh6WOoE/+nwUDa3uA==
+"@swc/core-win32-ia32-msvc@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-win32-ia32-msvc/-/core-win32-ia32-msvc-1.3.83.tgz#7757277e8618a638cb89e51a1e0959417eec6441"
+ integrity sha512-POW+rgZ6KWqBpwPGIRd2/3pcf46P+UrKBm4HLt5IwbHvekJ4avIM8ixJa9kK0muJNVJcDpaZgxaU1ELxtJ1j8w==
-"@swc/core-win32-x64-msvc@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core-win32-x64-msvc/-/core-win32-x64-msvc-1.3.84.tgz#93964a76d100df255e97739165d5d74c72d7c88b"
- integrity sha512-WmpaosqCWMX7DArLdU8AJcj96hy0PKlYh1DaMVikSrrDHbJm2dZ8rd27IK3qUB8DgPkrDYHmLAKNZ+z3gWXgRQ==
+"@swc/core-win32-x64-msvc@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core-win32-x64-msvc/-/core-win32-x64-msvc-1.3.83.tgz#92da90b84a9b88fdd92b6d1256fd6608e668541f"
+ integrity sha512-CiWQtkFnZElXQUalaHp+Wacw0Jd+24ncRYhqaJ9YKnEQP1H82CxIIuQqLM8IFaLpn5dpY6SgzaeubWF46hjcLA==
-"@swc/core@1.3.84":
- version "1.3.84"
- resolved "https://registry.yarnpkg.com/@swc/core/-/core-1.3.84.tgz#e6e660f0a2e322fb17698f3ca9b23dfacc0933f1"
- integrity sha512-UPKUiDwG7HOdPfOb1VFeEJ76JDgU2w80JLewzx6tb0fk9TIjhr9yxKBzPbzc/QpjGHDu5iaEuNeZcu27u4j63g==
+"@swc/core@1.3.83":
+ version "1.3.83"
+ resolved "https://registry.yarnpkg.com/@swc/core/-/core-1.3.83.tgz#2902e0bc5ee9c2fcdfb241c8b993c216bc730fe5"
+ integrity sha512-PccHDgGQlFjpExgJxH91qA3a4aifR+axCFJ4RieCoiI0m5gURE4nBhxzTBY5YU/YKTBmPO8Gc5Q6inE3+NquWg==
dependencies:
"@swc/types" "^0.1.4"
optionalDependencies:
- "@swc/core-darwin-arm64" "1.3.84"
- "@swc/core-darwin-x64" "1.3.84"
- "@swc/core-linux-arm-gnueabihf" "1.3.84"
- "@swc/core-linux-arm64-gnu" "1.3.84"
- "@swc/core-linux-arm64-musl" "1.3.84"
- "@swc/core-linux-x64-gnu" "1.3.84"
- "@swc/core-linux-x64-musl" "1.3.84"
- "@swc/core-win32-arm64-msvc" "1.3.84"
- "@swc/core-win32-ia32-msvc" "1.3.84"
- "@swc/core-win32-x64-msvc" "1.3.84"
+ "@swc/core-darwin-arm64" "1.3.83"
+ "@swc/core-darwin-x64" "1.3.83"
+ "@swc/core-linux-arm-gnueabihf" "1.3.83"
+ "@swc/core-linux-arm64-gnu" "1.3.83"
+ "@swc/core-linux-arm64-musl" "1.3.83"
+ "@swc/core-linux-x64-gnu" "1.3.83"
+ "@swc/core-linux-x64-musl" "1.3.83"
+ "@swc/core-win32-arm64-msvc" "1.3.83"
+ "@swc/core-win32-ia32-msvc" "1.3.83"
+ "@swc/core-win32-x64-msvc" "1.3.83"
"@swc/jest@0.2.29":
version "0.2.29"