PHPackages                             jasonterando/config-validator - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Validation & Sanitization](/categories/validation)
4. /
5. jasonterando/config-validator

ActiveLibrary[Validation & Sanitization](/categories/validation)

jasonterando/config-validator
=============================

Utility to collect and validate configuration information

0.1.0(8y ago)0121MITPHPPHP ^5.6 || ^7.0

Since Apr 4Pushed 7y ago1 watchersCompare

[ Source](https://github.com/jasonterando/configuration-validator)[ Packagist](https://packagist.org/packages/jasonterando/config-validator)[ Docs](https://github.com/jasonterando/configuration-validator/)[ RSS](/packages/jasonterando-config-validator/feed)WikiDiscussions master Synced 2mo ago

READMEChangelogDependencies (2)Versions (3)Used By (0)

Configuration Validator
=======================

[](#configuration-validator)

Overview
--------

[](#overview)

This is an Autoload implemented utility that provides a mechanism to ensure that deployed configuration files meet the requirements of any dependencies. It is meant to be executed in development or at the time of deployment.

An application and/or its dependencies each define a configuration definition file. When the Configuration Validation utility is executed, the utility compares the Application Configuration versus and Configuration Definitions inlcuded in dependencies.

Currently, Configuration Definition files are located using directories included Autoload PSR-4 and Classmap directories. Application Configuration files are retrieved using Zend's module manager convention (module\_listener\_options/module\_paths). It's envisioned that additional mechanisms to retrieve Configuration Definitions and Application Configurations will be added in the future.

Installation and Usage
----------------------

[](#installation-and-usage)

### Installation

[](#installation)

To use this:

1. Run `composer require jasonterando/configuration-validator`
2. Add the composer script lines to composer.json

```
{
    "scripts": {
        "config-validate": "ConfigurationValidator\\Scripts::ConfigValidate",
        "config-save-template": "ConfigurationValidator\\Scripts::ConfigSaveTemplate"
    }
}

```

### Usage

[](#usage)

From the application's main directory, run `composer config-validate` to run the validation. If everything checks out, a success message will be displayed and the exit code will be zero.

If the validation fails, due to missing or invalid configuration entries, warnings will be displayed and the exit code will be -2.

If the validation cannot run due to a fatal error, the exception message will be displayed and the exit code will be -1.

If you need to create a configuration validation file from scratch, you can run `composer config-save-template` which will create a definition file, based upon the application's current configuration, that you can refine and include with your module/library. Note that this file will include *all* application configuration, so you will want to remove entries that aren't required by your specific module, and likely set some types, before moving the file to your module's folder.

Both of the Composer scripts shown above can be run with the `debug` argument to provide more information about what files are being accessed.

### CI/CD Integration

[](#cicd-integration)

During deployment, after installing/updating configuration files, run `composer config-validate` to validate the configuration. Any exit code other than zero should be treated as a failure and stop the deployment.

Configuration Definitions
-------------------------

[](#configuration-definitions)

### Configuration Definition File Format

[](#configuration-definition-file-format)

Configuration Definition files are in YAML format. They can be named `config-definition.yaml` or `config-definition.yml`, and located in any directory defined as a PSR-4 or Classmap path in an Autoload project's composer.json. For example:

```
service1:
   endpoint: url
   credentials:
      key: string
      secret: string
options:
   timeout:
      type: integer
      required: false
   logo: file
   logs: directory
   copyright

```

Every leaf in the tree corresponds to a Configuration Item, located with the hiearchy of its parent nodes. Configuration Items have two properties, *type* and *required*. By default, Configuration Items can be of *any* type, and are required.

In the example above, the final Configuration Item, "copyright" can be any value, but must exist in the Application Configuration. The "timeout" property is not requiredto exist in the Application Configuration file, but must be an integer (whole number) if it is.

There are two entries, "logo" and "logs" which must be an existing file and directory, respectively. Note that this check is done withing the user context that the test is run, which may not be the same as the context the application itself runs in, so this isn't a 100% foolproof check.

For "service1", its endpoint Configuration Item is required and must be a valid URL. The "key" and "secret" Configuration Items are required to be defined (under "credentials") and be non-empty strings.

For this example, a working configuration file may look something like this:

```