-
-
Notifications
You must be signed in to change notification settings - Fork 196
Description
Using a server (https://symfony.sh) to define the Recipes is an excellent initiative for open-source packages, allowing to create an automatic configuration for Symfony even if the author of the package didn't include / doesn't wish to include this configuration. It is a practice more and more used, in particular in the world of javascript, like TypeScript type definitions for example.
However, the repositories symfony/recipes and symfony/recipes-contrib are public, and require approval to add or modify their manifests and their configurations (manual and strict for official
, semi-automatic if I understood correctly for contrib
). This approach is therefore not suitable for private packages.
Questions are beginning to be asked about this on the Medium Symfony 4: Contributing Recipes, With an approach to create a private server, And asking the question about opening the source code of symfony.sh to create this private server.
I'm not against this approach quite the opposite, it sounds like creating a Satis server for Composer. However, it would be simpler/quicker to add the manifest and configurations to a dedicated directory in the repository. Just like Composer, that we can add repositories that are not referenced in Packagist or a Satis private server by using the VCS Repository. But unlike the VCS Repositories of Composer, the performance are not impacted, quite the opposite (no HTTP request).
The path to the Recipe directory might will have a default value (./recipe/
or other), with a possibility to change this value in the composer.json
file with the extra.symfony.recipe-path
key (or another name). If this directory exists in the repository with the manifest.json
file, in this case, no request is done on the symfony.sh
server.
This approach can be easily implemented given that the automatic configuration is performed just after the installation of the dependency and added just before the search of recipe on the symfony.sh server (in Symfony\Flex\Flex::filterPackageNames()
.
To summarize the workflow after the installation of package:
- Check the presence of the key
extra.symfony-recipe-path
incomposer.json
file of package - Get the real path of package recipe
- Check if the
manifest.json
file is present and valid - If package recipe is valid, install the automatic configuration from package source code
- Else, search recipe in symfony.sh server and install the automatic configuration from remote recipe if recipe is present on the server (the current behavior)
What do you think?