Download the PHP package antfroger/progressive without Composer

On this page you can find all versions of the php package antfroger/progressive. 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 antfroger/progressive

Informations about the package progressive

Progressive

Progressive is a feature flag library (also called toggle, switch, ...).
Thanks to Progressive, you can progressively, quickly and simply enable new features. (and just as quickly deactivate them in case of an emergency)

Build Status Latest Stable Version

Installation

Usage

Rules

Built-in

enabled: true|false

enabled enables (or disables) the feature for everyone, everywhere, all the time.
The value is meant to be a boolean, true|false.

Custom

You will probably need many more rules that will fit your needs and stack.

Let's say you want to redesign your homepage and progressively displaying it to test if everything goes right.
You start by enabling it in dev, then preprod, then prod but only for developers, then admins, then 1% of the users...
How would you be able to achieve that?

With custom rules!

(this lambda can be improved thanks to the Context object - more about it here)

Strategies

Rules are great but sometimes one rule is not enough to decide if a feature must be enabled.
You may want to enable a feature in PROD only for admins but to everyone in DEV, TEST and PREPROD.
Or you may want to enable a feature to the admins AND a given percentage of users.

That's where strategies come into play!

(Strategies are simply another name for nested rules.
And as for rules, you can create your own strategies!)

Progressive comes with two built-in strategies:

unanimous: []

unanimous enables the feature if all the conditions are met.
The value is meant to be an array of rules.

In this example, the interface to translate the app will only be displayed in DEV and PREPROD environments to users having ROLE_ADMIN or ROLE_TRANSLATOR as roles.
This strategy can be defined as an AND.

partial: []

partial enables the feature if only one of the conditions is met.
Rules are evaluated one by one. The feature is enabled as soon as one rule is true.
The value is meant to be an array of rules.

In this example, the interface to translate the app will be displayed:

This strategy can be defined as an OR.

Context object

Progressive doesn't know anything of your application logic code (and doesn't want to know).
But you may want to use your logic inside custom rules.

In that case, the context object is your friend!
It's nothing more that an user-defined databag.

You can use it to improve our previous custom rule:

Another common example is to store the current user in the context:

Requesting a non-existing flag

Whenever you request an non-existing flag, isEnabled will return false.
The flag is considered disabled.

Separate feature releases from code deploy

As Progressive takes an array of config, it makes it possible to decorrelate the release calendar from the code deployment.
In this example, we use the Symfony Yaml component to read the config from a YAML file.

Imagine that you are able to deploy the config files independently from your code base, you could release a new feature without having to deploy all your code base, by redeploying only /your-own-config-file.yaml.

You may also want to store the configuration in a database and pass it as an array to Progressive.

Progressive in your projects

Inspired by Laurent Callarec's javascript feature-flag library Banderole

All versions of progressive with dependencies

PHP Build Version
Package Version
Requires php Version ^7.3 || ^8.0
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 antfroger/progressive contains the following files

Loading the files please wait ....