Download the PHP package pablojoan/feature without Composer

On this page you can find all versions of the php package pablojoan/feature. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of pablojoan/feature

Informations about the package feature

GitHub license

Requires PHP 8.3 and above.

Installation

Basic Usage

For a quick summary and common use cases, please read the rest of this README.

Feature API

Feature flagging API used for operational rampups and A/B testing.

The Feature API is how we selectively enable and disable features at a very fine grain as well as enabling features for a percentage of users for operational ramp-ups and for A/B tests. A feature can be completely enabled, completely disabled, or something in between and can comprise a number of related variants.

The two main API entry points are:

which returns true when my_feature is enabled and, for multi-variant features:

which returns the name of the particular variant which should be used.

The single argument to each of these methods is the name of the feature to test.

A typical use of $features->isEnabled for a single-variant feature would look something like this:

For a multi-variant feature, we can determine the appropriate code to run for each variant with something like this:

If a feature is bucketed by id, then we pass the id string to $features->isEnabled and $features->getEnabledVariant as a second parameter

Configuration cookbook

There are a number of common configurations so before I explain the complete syntax of the feature configuration stanzas, here are some of the more common cases along with the most concise way to write the configuration.

A totally enabled feature:

A totally disabled feature:

Feature with winning variant turned on for everyone

Single-variant feature ramped up to 1% of users.

Multi-variant feature ramped up to 1% of users for each variant.

Enabled for 10% of regular users.

Feature ramped up to 1% of requests, bucketing at random rather than by id

Feature ramped up to 40% of requests, bucketing by id rather than at random

Single-variant feature in 50/50 A/B test

Multi-variant feature in A/B test with 20% of users seeing each variant (and 40% left in control group).

Configuration details

Each feature’s config stanza controls when the feature is enabled and what variant should be used when it is.

The value of a feature config stanza is an array with a number of special keys, the most important of which is 'variants'.

The value of the 'variants' property an array whose keys are names of variants and whose values are the percentage of requests that should see each variant.

The remaining feature config property is 'bucketing'. Bucketing specifies how users are bucketed when a feature is enabled for only a percentage of users. The default value, 'random', causes each request to be bucketed independently, meaning that the same user will be in different buckets on different requests. This is typically used for features that should have no user-visible effects but where we want to ramp up something like the switch from master to shards or a new version of JS code.

The bucketing value 'id', causes bucketing to be based on the given id.

Errors

There are a few ways to misuse the Feature API or misconfigure a feature that may be detected. (Some of these are not currently detected but may be in the future.)

  1. Setting the percentage value of a variant in 'variants' to a value less than 0 or greater than 100.

  2. Setting 'variants' such that the sum of the variant percentages is greater than 100.

  3. Setting 'variants' to a non-array value.

  4. Setting 'bucketing' to any value that is not 'id' or 'random'.

All versions of feature with dependencies

PHP Build Version
Package Version
Requires php Version >=8.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package pablojoan/feature contains the following files

Loading the files please wait ....