Patterns using /**/ do not recursively match sub directories and instead stop at the current depth. This seems to be a limitation of the php glob function but I think this would be a nice feature to have.

Originally posted by @marcelto at zendframework/zend-config-aggregator#10

BC Break Report

After running the application on Windows.

PHP Warning:  rename(C:\Users\****\AppData\Local\Temp\2\test.php.tmp,test.php): Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (code: 32) in D:\Apache_idpm\htdocs\test-config-cache.php on line 18

Warning: rename(C:\Users\****\AppData\Local\Temp\2\test.php.tmp,test.php): Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (code: 32) in D:\Apache_idpm\htdocs\test-config-cache.php on line 18

Summary

When executing any scripts or running the application the error above appears.
It seems that the function ConfigAggregator::cacheConfig generate a file in the sys_temp_dir and then try to rename the source file to the desired filename.

I tried to check if a process where using the source file with the service Process explorer but no results found.

Previous behavior

The file config-cache.php is generated in the data folder.

Current behavior

No file config-cache.php is generated and the error above appears.

How to reproduce

The sys_temp_dir is default to C:\Users\****\AppData\Local\Temp
This is a simple php script to reproduce the behaviour on Windows.

$cachedConfigFile='test.php';
$tempFile=sys_get_temp_dir() . DIRECTORY_SEPARATOR . basename($cachedConfigFile) . '.tmp';
$fh = fopen($tempFile, 'c');
//chmod($tempFile, '0777');
ftruncate($fh, 0);
fputs($fh,'test');
rename($tempFile, $cachedConfigFile);
fclose($fh);

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency phpunit/phpunit to v11

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Feature Request

Summary

I recently detected some duplicate entries within the config provider array which is passed to the ConfigAggregator#__construct. Since it requires the config to be merged multiple times while it makes no sense, I'd say we could add some validation to the ConfigAggregator#__construct to at least report duplicated class-string and/or function-string values.

WDYT?

Feature Request

Summary

Right now it is not possible to use closures in a ConfigProvider or PHP Config file if config caching is enabled (ConfigAggregator::ENABLE_CACHE => true).

Example:

// config/autoload/dependencies.global.php
return [
    'dependencies' => [
        'factories'  => [
            SomeService::class => fn() => new SomeService(),
        ],
    ],
];

When calling the application and thus calling \Laminas\ConfigAggregator\ConfigAggregator::__construct() the first request will be fine and working like expected, also the cached config is generated and sucessfully written to config_cache_path.

On the second call the config is read from the cache file and will fail with the following exception message:

$ php bin/console.php 
PHP Fatal error:  Uncaught Error: Call to undefined method Closure::__set_state() in /example/data/cache/config-cache.php:186
Stack trace:
#0 /example/vendor/laminas/laminas-config-aggregator/src/ConfigAggregator.php(257): require()
#1 /example/vendor/laminas/laminas-config-aggregator/src/ConfigAggregator.php(76): Laminas\ConfigAggregator\ConfigAggregator->loadConfigFromCache()

This is due to the fact that PHP natives var_export is used to generate the cache file contents, see: https://github.com/laminas/laminas-config-aggregator/blob/1.2.2/src/ConfigAggregator.php#L281

Proposed solution

Instead of the PHP native var_export function the ConfigAggregator should optionally use a library that is able to export closures into a native PHP array.

I successfully implemented a POC using brick/varexporter by @BenMorel that provides a drop in replacement for var_export and is able to export closures.

Rational

Problem

A typical service in a laminas/mezzio application uses a separate factory class to resolve dependencies from the ContainerInterface and to instantiate the service.

<?php

namespace App\Api\Search;

use Doctrine\DBAL\Connection;
use Psr\Container\ContainerInterface;
use Psr\Logger\LoggerInterface;

final class SearchRepositoryFactory
{
    public function __invoke(ContainerInterface $container): SearchRepository
    {
        return new SearchRepository(
            $container->get(Connection::class),
            $container->get(LoggerInterface::class),
        );
    }
}

Additionally the factory must be registered in the config file or a ConfigProvider like so:

return [
    'dependencies' => [
        'factories'  => [
            SearchRepositoryFactory::class => SearchRepositoryFactory::class,
        ],
    ],
];

This is a lot of boilerplate code to introduce a new service into an application.

Proposed solution

With the introduction of Arrow functions in PHP 7.4 the factory code can be written in a very lean way in the config provider or config file like this:

<?php

use Doctrine\DBAL\Connection;
use Psr\Container\ContainerInterface;
use Psr\Logger\LoggerInterface;

return [
    'dependencies' => [
        'factories'  => [
            SearchRepository::class => fn (ContainerInterface $container) => new SearchRepository(
                $container->get(Connection::class),
                $container->get(LoggerInterface::class),
            ),

            AnotherService::class => fn (ContainerInterface $container) => new AnotherService(
                $container->get(LoggerInterface::class),
                $container->get(SystemClock::class)
            ),
        ],
    ],
];

In my opinion the this provides a good middle ground between the convenience of the ReflectionBasedAbstractFactory and the control and performance of manually written factory classes.

I'm not proposing to get rid of all factory classes but only factory classes that contain no logic but resolving and instantiating the given service class.
I'm still using dedicated factory class for any object construction logic that is more complicated.

Performance Considerations

The exported closures look like the following in the generated cache files:

        'factories' => [
            'App\\Api\\Search\\SearchRepository' => function (\Psr\Container\ContainerInterface $container) {
                return new \App\Api\Search\SearchRepository($container->get(\Doctrine\DBAL\Connection::class));
            },
        ]

Performance related questions:

• Can the generated cache file still be picked up into the opcache
• Is calling the closures slower than calling instantiating and calling factory classes?

Alternative approaches

• https://github.com/reinfi/zf-dependency-injection

Questions

• How do you feel generally about using Arrow functions instead of factory classes?
• Can a third party library like brick/varexporter be a viable solution to export closures in the cached config file?
• How should this be implemented
  • brick/varexporter could be used a soft dependecy and used instead of the native function when available
• Are you open for an PR implementing the proposed solution either as a separate ConfigAggregator or as the soft dependency or maybe a postprocessor? I'm open for implementation ideas.

Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

Feature Request

Summary

Psalm is now able to properly understand something like:

object&callable(array):array

This would reduce errors with post processors being instantiated before being passed to the ConfigAggregator::__construct.

Example:

$parameterPostProcessor = new \Laminas\ConfigAggregatorParameters\LazyParameterPostProcessor(fn () => []);
$aggregator = new \Laminas\ConfigAggregator\ConfigAggregator([], null, [$parameterPostProcessor]);

This leads to an error:

InvalidArgument - config/config.php:45:50 - Argument 3 of Laminas\ConfigAggregator\ConfigAggregator::__construct expects list<callable(array<array-key, mixed>)|class-string>, but list{Laminas\ConfigAggregatorParameters\LazyParameterPostProcessor<array<string, mixed>>} provided (see https://psalm.dev/004)

To fix this, adding object&PostProcessorCallable and object&PreProcessorCallable to the annotation should fix the problem.
Something like this was also introduced in laminas-servicemanager with v4.0 and is supported by both psalm and phpstan.

RFC

Goal

laminas/laminas-modulemanager has a great feature that allows modules to be in a dependency tree. I would like a similar feature in this component.

There should be no changes to the current mechanisms, but dependent providers should be obtained and required in the order that they first appear, ahead of the ConfigProvider that requires them. (Edit: A clarification on this last point, and not my original intention but after a good suggestion by @boesing, the current list of providers in config.php should be considered as the first appearance if a provider is listed there).

Background

It is always necessary at the application level to include the ConfigProvider from all components used, even if there is no application code that specifically relies on those components (as they would be required and used internally by the external component). This can often lead to not knowing about providers that also need adding and there is no check to ensure that they are, nor any sufficient error message to explain to the user that this is the case.

Considerations

To use the new proposed mechanism should be an opt-in, and not require changes for those applications or components that do not wish to use it. This should be checked only the once and not affect the performance of retrieving from cache. Dependent providers should only be included once, and in the order that they first appear in the tree.

Since the changes would need to be made to provider loading, doing this as an external package would not be possible without also providing a modified ConfigAggregator.

Proposal(s)

I propose to introduce a new interface which requires a method providing a list of direct dependent ConfigProvider classes. This component would then check for this interface and prepend those required classes to the list of providers.

Appendix

Possible interface (names are just my first suggestions):

interface HasConfigProviderDependencies
{
    /**
     * @return iterable Array or \Iterator of provider dependencies. These are string values representing
     *     classes that act as providers. They must be instantiable without constructor arguments.
     */
    public function configProviderDependencies(): iterable;
}

Similar to/overlap with:

• laminas/laminas-modulemanager#3