Open NielsdeBlaauw opened 2 years ago
@NielsdeBlaauw It's actually possible to modify most of the behavior in SatisPress by extending or replacing the dependencies in the container. In this case, you can accomplish the same thing by doing something like this:
class MyRepositoryTransformer extends \SatisPress\Transformer\ComposerRepositoryTransformer {
protected function transform_item( Package $package ): array {
$data = parent::transform_item( $package );
// Filter data here.
return $data;
}
}
// Replace the Composer repository transformer dependency in the container.
add_action( 'satispress_compose', function( $plugin, $container ) {
$container['transformer.composer_repository'] = function( $container ) {
return new MyRepositoryTransformer(
$container['transformer.composer_package'],
$container['release.manager'],
$container['version.parser'],
$container['logger']
);
};
}, 10, 2 );
Hi @bradyvercher, seeing that #188 didn't make it into https://github.com/cedaro/satispress/releases/tag/v2.0.0, I wanted to bump here once more because I still think adding this filter to SatisPress would be a no-brainer while being helpful for cases like this (from https://github.com/cedaro/satispress/pull/188#pullrequestreview-2090418231):
In our current case, we must add the Composer replace
property to a specific package for certain reasons. So, instead of having to replace the repository transformer, we solve this with a tiny mu-plugin like the following:
add_filter(
'satispress_package_repository_item',
static function(array $composerData, \SatisPress\Package $package): array {
if ($package->get_name() !== 'satispress/foo') {
return $composerData;
}
return array_map(function($data) {
$data['replace'] = [
'bar/foo' => 'self.version'
];
return $data;
}, $composerData);
},
10,
2
);
This works just fine and is much less code than the effort required to achieve this with satispress_compose
, so I'd highly appreciate it if you reconsidered adding the filter.
Thank you very much!
@tyrann0us While I can appreciate that it is less code, I tried not to introduce external APIs like apply_filters
through the codebase. There are a few for backwards compat and where it would make things much easier (refactoring to make things more configurable would be more ideal), but I'm kinda hesitant to add more where there's already a clear way to do what you're trying to do.
I want to add some metadata to a package, such as:
Adding an
apply_filters
call allows developers to extend satispress capabilities.