• [x] Add a ConfigInterface
• [x] Break file loaders into separate classes, implementing ConfigLoader interface
• [x] ~~Check MIME type of file rather than extension~~
• [x] Add a simple(r) way of defining default options
• [ ] ~~Add a proxy class (shameless self-plug)~~
• [x] Add Scrutinizer
• [x] Add extension aliases
• [ ] Get some nice documentation in
• [ ] HHVM support

It add support for parsing strings and specifying file and string parsers. It closes #108 and closes #51. It also closes #109. It also fixes some styling and tests.

Documentation is also updated.

In my PROJECT_ROOT/config/app.config.php:

<?php

return [ 
    'manifest' => __DIR__ . '/../public/build/manifest.json',
    // ...
];

Now __DIR__ is evaluated to PROJECT_ROOT/vendor/hassankhan/config/src/Parser due to the eval() in https://github.com/hassankhan/config/blob/f33748ba6b2d2353e4c93ad830bfb26a2a00d2b2/src/Parser/Php.php#L37

Previous in version 1.x, it's evaluated to PROJECT_ROOT/config which is expected because of using require $file; implementation.

I notice that all files are now always evaluated as strings.

https://github.com/hassankhan/config/blob/f33748ba6b2d2353e4c93ad830bfb26a2a00d2b2/src/Config.php#L97

Could we provide a way to just require a PHP file? I don't think most people would like to load a PHP FILE config as a string and then evaluate it since it could be simply loaded with require and provide better results.

https://github.com/hassankhan/config/blob/f33748ba6b2d2353e4c93ad830bfb26a2a00d2b2/src/Parser/Php.php#L30-L33

Just another concern. What if I have ?> in a string such as

<?php

return [
    'condition1' => '?>count',
    'condition2' => 'count<?',
    'php_starting_tag' => '<?php',
];

It could be simplified into $config = str_replace(['<?php', '<?', '?>'], '', $config); by the way.

Add support for writing configuration files. This would be useful so developers could make user-friendly installers for configuration files.

For INI, XML, JSON, YAML and other formats, this should not be hard, because they already support writing. For PHP files, this could be harder.

Example of writing config from start:

// Instantiation
$conf = new Config();

// Setting value using key
$conf->set('debug', true);
$conf['debug'] = true;

// Setting value using nested key
$conf->set('security.secret', 'eXaMpLe');
$conf['security.secret'] = 'eXaMpLe';
$conf['security']['secret'] = 'eXaMpLe';

// Setting all values from array
$settings = array(
    'debug' => true,
    'security' => array(
        'secret' => 'eXaMpLe',
        'password' => '1234'
    ),
    'app.timeout' => 3000,
    'app.name' => 'Website'
);
$conf->set('', $settings);
$conf->all() = $settings;
$conf = $settings;

// Writing to file
$conf->write('config.json');

Example of writing using existing config:

// Instantiation
$conf = new Config('config.json');

// Setting value using key
$conf['debug'] = true;

// Writing to existing file (file should now have all previous settings and new ones)
$conf->write();

// Writing to new file (file should now have all previous settings from other file and new ones)
$conf->write('config.yml');

It seems that the Config class is missing an array_merge() like the AbstractConfig does.

Right now if I add a default configuration, it will get ignore since $this->data is not merge with the getDefaults() method.

Not sure if you'd want this in the library, but we could implement the ArrayAccess interface to allow for array-style get-set operations. The following would both be the same thing:

$config->get('key');
$config['key'];

Hey!

This pull request is a proposal to add "container-interop" compatibility to "config". As you can see, this pull request is... wooh... 3 lines long :)

Config already complies with container-interop's ContainerInterface. The only thing we have to do is add the interface.

Why would we want to do that?

Container-interop is a common interface for dependency injection containers. Containers usually store services, but they can also store parameters. container-interop does not do any distinction between services and parameters. In container-interop vocabulary, containers are used to store "entries" (they can be either services or parameters... or whatever!)

Config could therefore be considered as a container providing config parameters. And this is absolutely great, because this means that any container compatible with container-interop (and there are a bunch of them!) would be able to fetch data from the Config container (one of the big ideas of container-interop is to allow a container to fetch parameters/service from other containers through delegate dependency lookup)

In short, this pull request makes it possible to use Config really easily with a hug range of different projects.

Disclaimer: I'm one of container-interop authors, and I'm also the editor of PSR-11 (with @mnapoli) that is currently in discussion and planning to transform container-interop into a PSR.

Similar to issue #16. Syntax here: http://ne-on.org/ It's made by/for Nette framework. These both issues would make this package usable for almost every framework.

I'd be for standalone repositories with suggestion in composer:

• noddlehaus/config-yaml
• noddlehaus/config-neon

I can send PR for this support.

config file:

<?php
return [
    "1001"=>[
        'appsecret'=>"46fc45f1300d15bd89347b9ec0f02f58",
    ]
];

print_r(Config::load($configFile)->all());

Array
(
    [0] => Array
    (
        [appsecret] => 46fc45f1300d15bd89347b9ec0f02f58
    )
)

code tracking

./config/src/AbstractConfig.php line 40

public function __construct(array $data)
{
    $this->data = array_merge($this->getDefaults(), $data);
}

array_merge:

If the input arrays have the same string keys, then the later value for that key will overwrite the previous one. If, however, the arrays contain numeric keys, the later value will not overwrite the original value, but will be appended.

Demo Code

$this->config->set('database', array(
    'host' => 'localhost',
    'name' => 'mydatabase'
 ));

$this->config->set('database.host', '127.0.0.1');
$this->config->get('database'); //cache 

$this->config->set('database.port', 3306);
$this->config->get('database'); //cache

Reset cache data when use the function set? Recursive cache list and match it? Feeling is a daunting job.

Now the Config class accepts also:

• an array of files from which it gets all the keys using array_replace_recursive;
• a directory of files.

It refers to #18.

code:

$conf = Config::load('config.json');

^ config.json is a blank file, empty.

result: Fatal error: Uncaught Noodlehaus\Exception\ParseException: Syntax error in config.json:15 Stack trace: #0 \config-2.2.0\vendor\hassankhan\config\src\Parser\Json.php(29): Noodlehaus\Parser\Json->parse(NULL, 'config.json') #1 \config-2.2.0\vendor\hassankhan\config\src\Config.php(114): Noodlehaus\Parser\Json->parseFile('config.json') #2 \config-2.2.0\vendor\hassankhan\config\src\Config.php(79): Noodlehaus\Config->loadFromFile('config.json', Object(Noodlehaus\Parser\Json)) #3 \config-2.2.0\vendor\hassankhan\config\src\Config.php(64): Noodlehaus\Config->__construct('config.json', NULL, false) #4 \config-2.2.0\vendor\autoload.php(51): Noodlehaus\Config::load('config.json') #5 {main} thrown in config.json on line 15

The XML writer doesn't work on XML that contains attributes. I discovered this trying to modify my phpunit.xml.

Here's a passing test case with one of the project's own mocks:

$raw = <<<RAW
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <application>
        <name>configuration</name>
        <secret>s3cr3t</secret>
    </application>
    <host>localhost</host>
    <port>80</port>
    <servers>
        <server1>host1</server1>
        <server2>host2</server2>
        <server3>host3</server3>
    </servers>
</config>
RAW;
$config = new \Noodlehaus\Config($raw, new \Noodlehaus\Parser\Xml(), TRUE);
$xml = $config->toString(new \Noodlehaus\Writer\Xml(), TRUE);
print $xml;

Result:

<?xml version="1.0"?>
<config>
  <application>
    <name>configuration</name>
    <secret>s3cr3t</secret>
  </application>
  <host>localhost</host>
  <port>80</port>
  <servers>
    <server1>host1</server1>
    <server2>host2</server2>
    <server3>host3</server3>
  </servers>
</config>

Add an attribute to any element in the XML, and it will fail:

$raw = <<<RAW
<?xml version="1.0" encoding="UTF-8"?>
<config test="example">
    <application>
        <name>configuration</name>
        <secret>s3cr3t</secret>
    </application>
    <host>localhost</host>
    <port>80</port>
    <servers>
        <server1>host1</server1>
        <server2>host2</server2>
        <server3>host3</server3>
    </servers>
</config>
RAW;
$config = new \Noodlehaus\Config($raw, new \Noodlehaus\Parser\Xml(), TRUE);
$xml = $config->toString(new \Noodlehaus\Writer\Xml(), TRUE);
var_dump($xml);

Result:

<?xml version="1.0"?>

Fixes unsetting offset. Fixes #123.

Methods unset, offsetUnset and remove now delete offset from data and cache array. I used 1. solution from here.

We should now discuss if changing the interface is really such a breaking change. Are there actually any developers who actually implemented their own AbstractConfig? We can probably release as the minor/normal version, but just add in the release notes that interface is changed.