Feature flag naming patterns is an in-development, enterprise-only feature.
The pattern is defined in the project settings and is enforced when creating a new feature flag. The pattern is also enforced when creating a new feature flag via the API.
Patterns are implicitly anchored to the start and end of the string. This means that a pattern is matched against the entire new feature flag name, and not just any subset of it, as if the pattern was surrounded by
$. In other words, the pattern
[a-z]+ will be interpreted as
^[a-z]+$ and will match "somefeature", but will not match "some.other.feature".
Feature flag naming patterns are defined on a per-project basis.
In addition to the pattern itself, you can also define a an example and a description of the pattern. If defined, both the example and the description will be shown to the user when they are creating a new feature flag.
The naming pattern consists of three parts:
- Pattern (required)
- The regular expression that is used to validate the name of the feature flag. Must be a valid regular expression. Flags (such as case insensitivity) are not available.
- Example (optional)
- An example of a name that is valid according to the provided pattern. Note: the example must be valid against the described pattern for it to be saved.
- Description (optional)
- Any additional text that you would like to display to users to provide extra information. This can be anything that you think they would find useful and can be as long or short as you want.
For instance, you might define a pattern that requires all feature flags to follow a specific pattern, such as
^(red|blue|green|yellow)\.[a-z-]+\.[0-9]+$. You could then provide an example of a valid feature flag name (for instance "blue.water-gun.64") and a description of what the pattern should reflect: "