Config injector do not support escaped slashes in modules names

for example it wouldn't be able to find registered module Foo\Bar if it is registered like that:

<?php
return [
    'modules' => [
        'Foo\\Bar',
        'Application',
    ]
];

I think that the question

Please select which config file you wish to inject 'My\Package\ConfigProvider' into

should never appear if there's only one option that isn't "do not inject".

I think that the use-case for not installing into the default choice when there's only one choice is so esoteric and rare that the few users that don't need it can choose to use their VCS to remove the change to that file.

I've noticed each of the following:

• When zend-component-installer is present, and I re-install dependencies for a given application (e.g., rm -Rf vendor; composer install), the plugin prompts me for modules/components that already have config providers present in configuration. As an example, if I've previously installed zend-validator, and it has an entry present in config/config.php, it is not detected, and I am again prompted as to whether or not I want to inject it in my configuration.

• When using the module tooling from zend-expressive-tooling to deregister a module, it does not identify the module's ConfigProvider in the config/config.php, and thus does not correctly deregister it.

@weierophinney

Good evening,

Right now, it is possible to whitelist modules for automatic injection in zf config file. However, the target config file is always the same, that is, the modules.config.php file. I think that the development.config.php file (if available) should be preferred for injection when a package is listed as development dependencies (require-dev vs require).

Thanks you.

In new zf3 skeleton application there could be two development configs:

development.config.php
development.config.php.dist

By default installer suggests to inject module into dist config file.
But when development mode is enabled there is need to inject both files.

I think of that problem and find best way to solve it:

• create Chains for both: discovery and injectors collections
• pass Chains instead of appropriate classes

Also I provide PR. If it is correct I'll provide additional tests and also fix existing ones.

This seems like a bug to me. I can add --no-scripts which gives desired outcome but, I still think this is a bug.

Problem: Using composer install --no-interaction is injecting modules into modules.config.php.

Desired Outcome: using command should choose the default which is listed as Do Not Inject

- Installing doctrine/doctrine-module (1.2.0): Downloading (100%)

  Please select which config file you wish to inject 'DoctrineModule' into:
  [0] Do not inject
  [1] config/modules.config.php
  [2] config/development.config.php.dist
  Make your selection (default is 0):

- Installing zendframework/zend-form (2.12.0): Downloading (100%)

  Please select which config file you wish to inject 'Zend\Form' into:
  [0] Do not inject
  [1] config/modules.config.php
  [2] config/development.config.php.dist
  Make your selection (default is 0):

Default is set to Do not inject but, getting all of these modules injected anyway. Note the changes to the modules.config.php file after running this.

composer file being used:

{
    "name": "zfcampus/zf-apigility-skeleton",
    "description": "Skeleton Application for Apigility",
    "type": "library",
    "license": "BSD-3-Clause",
    "keywords": [
        "api",
        "apigility",
        "framework",
        "zf",
        "zendframework"
    ],
    "homepage": "http://apigility.org/",
    "support": {
        "issues": "https://github.com/zfcampus/zf-apigility-skeleton/issues",
        "source": "https://github.com/zfcampus/zf-apigility-skeleton",
        "rss": "https://github.com/zfcampus/zf-apigility-skeleton/releases.atom",
        "chat": "https://zendframework-slack.herokuapp.com",
        "forum": "https://discourse.zendframework.com/c/questions/apigility"
    },
    "config": {
        "process-timeout": 5000
    },
    "extra": {
        "branch-alias": {
            "dev-master": "1.5.x-dev",
            "dev-develop": "1.6.x-dev"
        }
    },
    "minimum-stability": "stable",
    "require": {
        "php": "^5.6 || ^7.0",
        "zendframework/zend-component-installer": "^1.1.1 || ^2.1.1",
        "zfcampus/zf-apigility": "^1.4",
        "zfcampus/zf-apigility-documentation": "^1.3",
        "zfcampus/zf-development-mode": "^3.2",
        "zfr/zfr-cors": "1.*",
        "guzzlehttp/guzzle": "^6.3",
        "elasticsearch/elasticsearch": "^5.3",
        "zfcampus/zf-apigility-doctrine": "^2.2",
        "doctrine/doctrine-mongo-odm-module": "^1.0",
        "mongodb/mongodb": "^1.4",
        "zfcampus/zf-doctrine-querybuilder": "^1.6",
        "phpunit/phpunit": "^7.3",
        "squizlabs/php_codesniffer": "^3.3"
    },
    "require-dev": {
        "zendframework/zend-developer-tools": "^1.2.1",
        "zendframework/zend-test": "^3.2",
        "zfcampus/zf-apigility-admin": "^1.6",
        "zfcampus/zf-asset-manager": "^1.2",
        "zfcampus/zf-composer-autoloading": "^1.1.1 || ^2.1",
        "zfcampus/zf-deploy": "^1.3"
    },
    "suggest": {
        "zfcampus/zf-apigility-doctrine": "zfcampus/zf-apigility-doctrine ^2.2 to create Doctrine-Connected REST services",
        "zfcampus/zf-http-cache": "zfcampus/zf-http-cache ^1.4 to add HTTP caching to your API",
        "zfr/zfr-cors": "zfr/zfr-cors ^1.5 to add CORS support to your API"
    },
    "autoload": {
        "psr-4": {
            "Application\\": "module/Application/src/",
            "ContentApi\\": "module/ContentApi/src/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "ApplicationTest\\": "module/Application/test/"
        },
        "files": [
            "src/Apigility/constants.php"
        ]
    },
    "scripts": {
        "cs-check": "phpcs",
        "cs-fix": "phpcbf",
        "development-disable": "zf-development-mode disable",
        "development-enable": "zf-development-mode enable",
        "development-status": "zf-development-mode status",
        "post-create-project-cmd": ["@development-enable"],
        "serve": "php -S 0.0.0.0:8080 -t public/",
        "test": "phpunit"
    }
}

I created a new Zend\Expressive application:

$ composer create-project zendframework/zend-expressive-skeleton 
$ cd zend-expressive-skeleton

Then I added the Component Installer:

$ composer require zendframework/zend-component-installer

After that I installed some components:

$ composer require zendframework/zend-form
$ composer require zendframework/zend-i18n

I thought that the ConfigProvider of these components should be added automatically to the config/config.php file. But nothing happened.

Is this a bug or just a misunderstanding by myself?

As I was trying to remove zend-form from my expressive application with Composer, I got the following message:

Fatal error: Uncaught Error: Call to undefined method Zend\ComponentInstaller\Injector\ConfigInjectorChain::getConfigFile() in phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(195) : eval()'d code:617
Stack trace:
#0 /app/apps/public/vendor/zendframework/zend-component-installer/src/Collection.php(75): Zend\ComponentInstaller\ComponentInstaller_composer_tmp0->Zend\ComponentInstaller\{closure}(Object(Zend\ComponentInstaller\Injector\ConfigInjectorChain), 1)
#1 phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(195) : eval()'d code(620): Zend\ComponentInstaller\Collection->each(Object(Closure))
#2 phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(195) : eval()'d code(597): Zend\ComponentInstaller\ComponentInstaller_composer_tmp0->removeModuleFromConfig('Zend\\Form\\Confi...', 'zendframework/z...', Object(Zend\ComponentInstaller\Collection))
#3 /app/apps/public/vendor/zendframework/zend-component-installer/src/Collection.php(75): Zend\ComponentInstaller\ComponentInstal in phar:///usr/local/bin/composer/src/Composer/Plugin/PluginManager.php(195) : eval()'d code on line 617

I guess this is caused by the call to getConfigFile present at line 617 of ComponentInstaller::removeModuleFromConfig, while that method is not present in InjectorInterface

PHP: 7.1.1
zend-component-installer version: 0.6.0:

Deprecation Notice: The callback Zend\ComponentInstaller\ComponentInstaller::onPostPackageInstall 
declared at /www/zfproject/vendor/zendframework/zend-component-installer/src/ComponentInstaller.php 
accepts a Composer\Script\PackageEvent but post-package-install
 events use a Composer\Installer\PackageEvent instance. 
Please adjust your type hint accordingly, see https://getcomposer.org/doc/articles/scripts.md#event-classes in 
phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:317

I have installed fresh skeleton. After this I enabled development mode:

composer zf-development-mode

and required developer tools

composer require --dev zendframework/zend-developer-tools

Component installer gave mi 3 options:

Please select which config file you wish to inject 'ZendDeveloperTools' into:
  [0] Do not inject
  [1] config/modules.config.php
  [2] config/development.config.php.dist

Hovewer there's no option to attach module to current development.config.php. After choose 2 option I needed to disable and enable again development mode to make developer tools working.

I think the problem is in the ComponentInstaller::injectModuleIntoConfig function which takes the first type the injector can handle, but this might be not the packageType that was defined in the composer.json.

That injectModuleIntoConfig function or the injector need to know, which packageType was extracted from the config.

Components VS Config Provider Prioritization

Does ConfigProviders (aka Modules) has the same priority with ZF2/3 Modules when it comes to injecting of dependencies in an Expressive application?

I was experimenting on my dependencies and upon observation, the zend-components (like zend-navigation, zend-validator, etc) are appended after my Config Providers (aka Modules).

$config = new ConfigAggregator(
    [
        \MyNamespace\WebHelper\ConfigProvider::class,
        \MyNamespace\ErrorHandler\ConfigProvider::class,
        \Zend\Router\ConfigProvider::class,
        \Zend\Validator\ConfigProvider::class,
        \Zend\Navigation\ConfigProvider::class,
        new PhpFileProvider('config/autoload/{{,*.}global,{,*.}local}.php'),
        new PhpFileProvider('config/development.config.php')
    ],
    __DIR__ . '/../data/cache/application.config.php'
);

Multiple Config Provider Prioritization

Since there is no priority settings in the configuration, I'm creating a separate metapackage (similar to zend-mvc-plugins) expecting that the order of the config providers should be maintained upon injection

If having this metapackage configuration:

"extra": {
        "zf": {
      	    "config-provider": [
                "MyNamespace\ExpressiveErrorHandler\ConfigProvider",
                "MyNamespace\ExpressiveWebHelper\ConfigProvider"
            ]
        }
    }

Expectation:

$config = new ConfigAggregator(
    [
        \MyNamespace\ErrorHandler\ConfigProvider::class,
        \MyNamespace\WebHelper\ConfigProvider::class,
        new PhpFileProvider('config/autoload/{{,*.}global,{,*.}local}.php'),
        new PhpFileProvider('config/development.config.php')
    ],
    __DIR__ . '/../data/cache/application.config.php'
);

Actual Result
It seems the prioritization is based on composers ability to pull packages. If the package has no (lesser) dependencies then the package will be injected (asked) first. But assuming that these packages are available, should the configuration be maintained?

@webimpress @weierophinney
This may be an enhancement but I love to know your points about this matter. Thanks in advance.

Related Issue/PR: #16

Add an option to read a list of whitelisted packages from the project composer file. Packages in that list are installed silently without the installation prompt. To prevent abuse, only a whitelist in the project composer file is allowed.

    "extra": {
        "zf": {
            "component-whitelist": [
                "zendframework/zend-expressive-router",
                "zendframework/zend-expressive-fastroute",
                "zendframework/zend-expressive-twigrenderer",
                "zendframework/zend-expressive-helpers"
            ]
        }
    },

• Update Travis configuration
• Check Travis results

Which, among all, causes https://docs.zendframework.com/zend-component-installer/ to miss documentation

It is a bit annoying to update it in composer. And for example even ZendSkeletonApplication uses outdated version (0.3.1 - 2016-09-12) https://github.com/zendframework/ZendSkeletonApplication/blob/release-3.0.1/composer.json#L16

The config file paths are currently hardcoded. IMHO that's a bad move. The framework is very flexible about file names and directory layout, and the paths (in particular for the "config" files in question) are actually provided by the application, not the framework. Forcing a directory layout in the top-level directory can interfere with the project structure and give a bad end-user experience. (I have such a project where the forced layout does not fit in at all.)

Would it be possible to make paths configurable via the project's composer.json? The current layout could still be used by default if not configured explicitly.

Alternatively, notifications about possible injection points could be provided if none of the predefined files exist or its contents are not suitable for automatic modification. That would allow developers to add things manually. Currently, the installer remains silent if it cannot do anything automatically, and developers aren't even aware that injections are available/required.

Deprecation Notice: The callback Zend\ComponentInstaller\ComponentInstaller::onPostPackageInstall declared at /home/runner/cdnperf.com/vendor/zendframework/zend-component-installer/src/ComponentInstaller.php accepts a Composer\Script\PackageEvent but post-package-install events use a Composer\Installer\PackageEvent instance. Please adjust your type hint accordingly, see https://getcomposer.org/doc/articles/scripts.md#event-classes in phar:///home/runner/.phpbrew/php/php-7.0.13/bin/composer.phar/src/Composer/EventDispatcher/EventDispatcher.php:308

Small change but backwards incompatible

Replacing mtymek/expressive-config-manager with zend-config-aggregator will cause bc breaks with existing applications consuming this package due to its (official) NAMESPACE (Zend\ConfigAggregator) - even though they are almost identical library.

Following change would be:

Zend\Expressive\ConfigManager\ConfigManager::class => Zend\ConfigAggregator\ConfigAggregator::class
Zend\Expressive\ConfigManager\PhpFileProvider => Zend\ConfigAggregator\PhpFileProvider

Why Zend\ConfigAggregator?

While designed for Expressive applications, it can work with any PHP project for aggregating and returning merged configuration, from either a variety of configuration formats or "configuration providers", invokable classes returning an array of configuration (or a PHP generator). It also supports configuration caching.

See: https://github.com/zendframework/zend-config-aggregator

What needs to be done?

• Update the injection of config provider namespace in ExpressiveConfigInjector and corresponding tests.

• Update the config provider discovery namespace in ExpressiveConfig and corresponding tests

• Update Document explaining the changes - with the new NAMESPACE (Zend\ConfigAggregator) and migration instruction.

I do believe the old Roadmap in there isn't of any use anymore?
Since the docs are located elsewhere this repo's empty wiki should be disabled.