Workflow
Projects
A Featurevisor project is intended to be used as a single standalone Git repository, separate from your application codebase.
Creating a project#
The easiest way is to use the Featurevisor CLI using npx (Node.js).
Initialize a new Featurevisor project:
$ npx @featurevisor/cli initInstallation#
Afterwards, install the dependencies:
$ npm installPlatform agnostic usage#
While Featurevisor project itself depends on Node.js, your applications do not need to.
The idea is that a Featurevisor project will generate datafiles (static JSON files), which will later be consumed by applications using SDKs in different programming languages which do not need to have any ties to Node.js in any way.
Options for a project#
A Featurevisor project can be initialized in multiple different setups, with:
- Multiple environments (recommended)
- No environments
- Sets
We can visualize the possible setups in a table below:
| Environments | Sets | Command | |
|---|---|---|---|
| 1 | ✅ | ❌ | npx @featurevisor/cli init |
| 2 | ❌ | ❌ | npx @featurevisor/cli init --example=no-environments |
| 3 | ✅ | ✅ | npx @featurevisor/cli init --example=sets |
| 4 | ❌ | ✅ | npx @featurevisor/cli init --example=environments |
Further details on how best to choose your setup:
- Multiple environments, no sets: recommended setup, where rules for multiple environments are defined in the same feature definition.
- No environments, no sets: for very simple use cases, where you only have a single environment and no sets.
- Multiple environments, multiple sets: useful when you wish to use a Featurevisor project like a monorepo for multiple different definition trees (think like a monorepo of projects).
- No environments, multiple sets: handy for imitating each environment as a separate set, with incremental linear promotions.
Below we will go through option number 1 from the table above.
Directory structure#
$ tree ..├── attributes/│ ├── country.yml│ ├── deviceId.yml│ └── userId.yml├── datafiles/ (generated later)│ ├── production/│ │ └── featurevisor-all.json│ └── staging/│ └── featurevisor-all.json├── features│ └── showCookieBanner.yml├── featurevisor.config.js├── package.json├── segments│ └── netherlands.yml├── targets│ └── all.yml└── tests ├── features │ └── showCookieBanner.spec.yml └── segments └── netherlands.spec.ymlProject configuration#
featurevisor.config.js: contains your project configuration. Learn more in Configuration page.
Building blocks#
These are the directories where you will be defining all the building blocks for managing your features:
attributes/: contains all your attribute definitionssegments/: contains all your reusable segments, which work as targeting conditionsfeatures/: contains all your feature definitionstargets/: contains your target definitions, which decide the datafiles that get builttests/: contains all your test specs against your features and segments
Output#
datafiles/: contains all your generated datafiles, which are meant to be consumed by SDKs in your applications
Git repository#
While it is intended that a Featurevisor project should be hosted in a standalone Git repository, it is not a strict requirement.
$ git init$ git add .$ git commit -m "Initial commit"You can still use the CLI to manage your project without a Git repository, or as part of your larger application codebase (think a monorepo setup).
However, it is highly recommended to use a standalone Git repository to keep track of your changes and collaborate with others. Keeping it separate from your application codebase allows you to decouple your feature changes from your application code deployments.

