Separate config file for apigility per module

[FranPregernik]

Hi,

I tried to use Apigility in an existing module where the config file has stuff like this:

<?php
namespace Demo; // <== THIS RIGHT HERE

use Demo\Controller\IndexController;

return [
    // ...
    'log' => [
        'log.demo' => [
            'writers' => [
                [  // <==== THIS RIGHT HERE
                    'name' => 'stream',
                    'priority' => 1000,
                    'options' => [
                        'stream' => 'data/logs/demo.log',
                    ],
                ],
            ],
        ],
    ],
    'translator' => [
        'locale' => 'en_US',
        'translation_file_patterns' => [
            [
                'type' => 'gettext',
                'base_dir' => __DIR__ . '/../language', // <==== THIS RIGHT HERE
                'pattern' => '%s.mo',
            ],
        ],
    ],
    'controllers' => [
        'invokables' => [
            'Demo\Controller\Index' => IndexController::class,  // <== THIS RIGHT HERE
        ],
    ],
    // ..
];

After using the admin interface it naturally added stuff of it's own to the config and in the process altered the config file. I understand why and how ZF\Configuration does what it does.

• Changed short array syntax [] to array() - this can be turned off
• Added number keys to arrays that didn't specify them
• Converted IndexController::class to it's string representation
• Converted DIR to the actual directory.
• Removes the namespace at the top

All of this also messes with your VCS of choice and you either have to revert some changes back or commit the changed config with the changes Apigility introduced.

<?php
// <== missing namespace Demo;

return [
    // ...
    'log' => [
        'log.demo' => [
            'writers' => [
                0 => [  // <==== THIS RIGHT HERE
                    'name' => 'stream',
                    'priority' => 1000,
                    'options' => [
                        'stream' => 'data/logs/demo.log',
                    ],
                ],
            ],
        ],
    ],
    'translator' => [
        'locale' => 'en_US',
        'translation_file_patterns' => [
           0 => [ // <== THIS RIGHT HERE
                'type' => 'gettext',
                'base_dir' => '/some/actual/path/../language', // <==== THIS RIGHT HERE
                'pattern' => '%s.mo',
            ],
        ],
    ],
    'controllers' => [
        'invokables' => [
            'Demo\Controller\Index' => 'Demo\\Controller\\IndexController',  // <== THIS RIGHT HERE
        ],
    ],
    // ..
];

I propose that Apigility uses a different file for it's config. The reason this makes sense to me is that we are already implementing a custom interface ApigilityProviderInterface in the module. The module class getConfig would have to merge these two together for it to work.

Implementing this could be done in several ways. Some of which are:

1. convention + manual loading: Demo/config/apigility.config.php and array_merge in getConfig
2. trait implementing pt. 1
3. Additional Interface with method getApigilityConfig + manual merge (e.g. ApigilityCustomConfigInterface)

I don't think it would be too much to ask the developer to do this since he is already following the tutorial on integrating Apigility into an existing module.

I would be happy to implement this if you think it is worthwhile in any way you seem fit.

Best regards,
Fran Pregernik

[kingkorf]

@FranPregernik @weierophinney Is this looked at/thought about already?

This could be realy helpfull during development, we keep getting merge conflicts in the module.config.php using git.

[FranPregernik]

@kingkorf - Not that I am aware of.

[jonrwads]

@kingkorf I agree about this being a pain point with a versioning system. We have about 6 devs constantly adding services to an API and I have yet to see a clean merge of this one file fits all architecture.

Something should be done to make this set up more team friendly.

[michalbundyra]

This repository has been closed and moved to laminas-api-tools/api-tools; a new issue has been opened at laminas-api-tools/api-tools#64.