Command Line Interface (CLI) Usage

Beyond just initializing a project and building datafiles, Featurevisor CLI can be used for a few more purposes.

Installation#

Use npx to initialize a project first:

$ mkdir my-featurevisor-project && cd my-featurevisor-project
$ npx @featurevisor/cli init

If you wish to initialize a specific example as available in the monorepo:

$ npx @featurevisor/cli init --example=json

After you have installed the dependencies in the project:

$ npm install

You can access the Featurevisor CLI from inside the project via:

$ npx featurevisor

Featurevisor finds featurevisor.config.js by walking up from the current directory. You can run commands from nested directories inside the project without changing back to its root.

To operate on another project, pass either form of the root directory option:

$ npx featurevisor build --rootDirectoryPath=../my-other-project
$ npx featurevisor build --root-directory-path ../my-other-project

Use npx featurevisor <command> --help or npx featurevisor help <command> to see the available options for a command. Help remains available outside a project and when a project configuration cannot be loaded.

Built in commands reject unknown options and unexpected positional arguments. This helps catch spelling mistakes before a command does any work. Custom plugins can opt into the same validation by declaring their options.

Learn more in Quick start.

Linting#

Check if the definition files have any syntax or structural errors:

$ npx featurevisor lint

Use --json for machine-readable output, and --json --pretty for prettified JSON output.

Learn more in Linting.

Building datafiles#

Generate JSON files, one per target and optional environment combination:

$ npx featurevisor build

Pass --target=<target> one or more times to build only those targets. Without it, all targets are built.

In a project with sets, you can build a single set by passing --set:

$ npx featurevisor build --set=storefront

Learn more in Building datafiles.

Testing#

Test your features and segments:

$ npx featurevisor test

Pass --target=<target> one or more times to build only those target datafiles and run untargeted assertions plus assertions for the selected targets. Segment tests are not filtered.

In a project with sets, you can test a single set by passing --set:

$ npx featurevisor test --set=storefront

Learn more in Testing.

Promote between sets#

In a project with sets, you can preview and apply promotions from one set to another.

Preview what would be copied:

$ npx featurevisor promote --from=dev --to=staging

Apply the promotion to write destination files:

$ npx featurevisor promote --from=dev --to=staging --apply

Learn more in Promotions.

Generate static catalog#

Build the catalog:

$ npx featurevisor catalog export

Serve the built catalog (defaults to port 3000):

$ npx featurevisor catalog serve

Serve it in a specific port:

$ npx featurevisor catalog serve -p 3000

Learn more in Catalog.

Generate code#

Generate TypeScript code from feature definitions:

$ npx featurevisor generate-code --language typescript --out-dir ./src

See output in ./src directory. Pass repeatable --tag=<tag> or --target=<target> options to generate the union of features needed by several tags or targets.

Learn more in code generation page.

Find duplicate segments#

It is possible to end up with multiple segments having same conditions in larger projects. This is not a problem per se, but we should be aware of it.

We can find these duplicates early on by running:

$ npx featurevisor find-duplicate-segments

If we want to know the names of authors who worked on the duplicate segments, we can pass --authors:

$ npx featurevisor find-duplicate-segments --authors

Find usage#

Learn where/if certain segments and attributes are used in.

Choose exactly one feature, segment, attribute, or unused entity query per command. Combining several queries is rejected so no selection is silently ignored.

For each of the find-usage commands below, you can optionally pass --authors to find who worked on the affected entities.

Segment usage#

$ npx featurevisor find-usage --segment=my_segment

Attribute usage#

$ npx featurevisor find-usage --attribute=my_attribute

Unused segments#

$ npx featurevisor find-usage --unusedSegments

Unused attributes#

$ npx featurevisor find-usage --unusedAttributes

Feature usage#

$ npx featurevisor find-usage --feature=my_feature

Benchmarking#

You can measure how fast or slow your SDK evaluations are for particular features.

The --n option is used to specify the number of iterations to run the benchmark for.

--n and the optional --inflate value must be positive integers. The --context value must be a JSON object. Invalid values are reported before the benchmark begins. --variation and --variable cannot be combined in one benchmark.

Pass --target=<target> one or more times to benchmark the same evaluation independently against each selected target datafile. Without it, the complete in-memory datafile is used.

The output includes both the total loop duration and individual evaluation timings:

• Total duration: how long all benchmark iterations took together
• Minimum duration: fastest individual evaluation
• Average duration: average individual evaluation
• Maximum duration: slowest individual evaluation

Use the individual evaluation timings when comparing SDK performance. The maximum value can include runtime pauses like garbage collection or process scheduling.

Feature#

To benchmark evaluating a feature itself if it is enabled or disabled via SDK's .isEnabled() method against provided context:

$ npx featurevisor benchmark \
  --environment=production \
  --feature=my_feature \
  --context='{"userId": "123"}' \
  --n=1000

Variation#

To benchmark evaluating a feature's variation via SDKs's .getVariation() method:

$ npx featurevisor benchmark \
  --environment=production \
  --feature=my_feature \
  --variation \
  --context='{"userId": "123"}' \
  --n=1000

Variable#

To benchmark evaluating a feature's variable via SDKs's .getVariable() method:

$ npx featurevisor benchmark \
  --environment=production \
  --feature=my_feature \
  --variable=my_variable_key \
  --context='{"userId": "123"}' \
  --n=1000

Configuration#

To view the project configuration:

$ npx featurevisor config

Printing configuration as JSON:

$ npx featurevisor config --json --pretty

Evaluate#

To learn why certain values (like feature and its variation or variables) are evaluated as they are against provided context:

$ npx featurevisor evaluate \
  --environment=production \
  --feature=my_feature \
  --context='{"userId": "123", "country": "nl"}'

This will show you full evaluation details helping you debug better in case of any confusion.

Pass --target=<target> one or more times to evaluate independently against the exact datafiles for those targets. With repeated targets and --json, the result is an array containing each target and its evaluations. A single target keeps the regular evaluation object shape.

It is similar to diagnostics in SDKs with debug level. But here instead, we are doing it at CLI directly in our Featurevisor project without having to involve our application(s).

If you wish to print the evaluation details in plain JSON, you can pass --json at the end:

$ npx featurevisor evaluate \
  --environment=production \
  --feature=my_feature \
  --context='{"userId": "123", "country": "nl"}' \
  --json \
  --pretty

The --pretty flag is optional.

To print further logs in a more verbose way, you can pass --verbose:

$ npx featurevisor evaluate \
  --environment=production \
  --feature=my_feature \
  --context='{"userId": "123", "country": "nl"}' \
  --verbose

List#

Choose exactly one entity type for every list command. Featurevisor reports an error if none or more than one are selected. Archived features, segments, and attributes are hidden by default. Pass --archived=true to list archived definitions, or --archived=false to request active definitions explicitly.

List datafiles#

To list generated datafiles in the configured datafiles/ directory:

$ npx featurevisor list --datafiles

The result is a three-column table of paths relative to datafiles/, their uncompressed sizes, and their gzip-compressed sizes, excluding the REVISION file and hidden files. Size values are right-aligned and always show two decimal places; one-character B suffixes are padded to align with kB and mB. There is an empty line between directories. Directories beginning with dev appear first and those beginning with prod appear last. Sizes use colored B, kB, and mB suffixes in terminal output. With --json, each item has path, byte size, and byte gzipSize fields in the same order.

List features#

To list all features in the project:

$ npx featurevisor list --features

Advanced search options:

List segments#

To list all segments in the project:

$ npx featurevisor list --segments

Advanced search options:

List attributes#

To list all attributes in the project:

$ npx featurevisor list --attributes

Advanced search options:

List groups#

To list exclusion groups:

$ npx featurevisor list --groups

Groups support --description, --keyPattern, --promotable, --json, and --pretty filters and output options.

List schemas#

To list reusable schemas:

$ npx featurevisor list --schemas

Schemas support --description, --keyPattern, --promotable, --json, and --pretty filters and output options.

List targets#

To list targets:

$ npx featurevisor list --targets

Targets support --description, --keyPattern, --promotable, --json, and --pretty filters and output options.

List tests#

To list all tests specs in the project:

$ npx featurevisor list --tests

Advanced search options:

Assess distribution#

To check if the gradual rollout of a feature and the weight distribution of its variations (if any exists) are going to work as expected in a real world application with real traffic against provided context, we can imitate that by running:

$ npx featurevisor assess-distribution \
  --environment=production \
  --feature=my_feature \
  --context='{"country": "nl"}' \
  --populateUuid=userId \
  --n=1000

The --n option controls the number of iterations to run, and the --populateUuid option is used to simulate different users in each iteration in this particular case.

The iteration count must be a positive integer, and --context must contain a JSON object.

Further details about all the options:

• --environment: the environment name
• --feature: the feature key
• --context: the common context object in stringified form
• --populateUuid: attribute key that should be populated with a new UUID, and merged with provided context.
  • You can pass multiple attributes in your command: --populateUuid=userId --populateUuid=deviceId
• --n: the number of iterations to run the assessment for
  • The higher the number, the more accurate the distribution will be
• --target: assess the exact target datafile; repeat it to assess several targets independently
• --verbose: print the merged context for better debugging

Everything is happening locally in memory without modifying any content anywhere. This command exists only to add to our confidence if questions arise about how effective traffic distribution in Featurevisor is.

Info#

Shows counts for attributes, segments, features, variables, groups, schemas, targets, test specs, and expanded test assertions in the project:

$ npx featurevisor info

Pass --target=<target> one or more times to show counts and datafile sizes for each selected target in each environment. Without it, info shows the project-wide entity counts.

Error output#

When a command fails, Featurevisor prints the message to standard error and exits with a non-zero code.

If --json is passed, the failure is printed as a structured object instead, which is easier to handle in scripts and CI:

{
  "error": {
    "code": "unknown_command",
    "message": "Unknown command \"frobnicate\".",
    "details": {
      "command": "frobnicate"
    }
  }
}

The code property is stable and meant to be matched against, while message is written for humans. The details object carries additional context when there is any, and is an empty object otherwise. Add --pretty to indent the output.

Codes you are most likely to encounter are invalid_cli_arguments for a misspelled option or an unexpected positional argument, unknown_command for a command that does not exist, project_not_found when no featurevisor.config.js could be found, and invalid_project_configuration when the configuration file could not be loaded.

Version#

Get the current version number of Featurevisor CLI, and its relevant packages:

$ npx featurevisor version

Or do:

$ npx featurevisor --version

Or do:

$ npx featurevisor -v