As a developer, I want to use a recipe with features removed, to gain flexibility

• [x] I can inline a recipe, transferring its requirements into my project
• [x] I can remove a module provided by the recipe, and it won't be added during a recipe-upgrade
• [x] I can remove a file provided by the recipe, and it won't be added during a recipe-upgrade

PRs

• [x] https://github.com/silverstripe/recipe-plugin/pull/3

Potential implementations

.gitignore

If a root project has a file pattern in .gitignore or .gitattributes then the plugin should probably not try to copy project files to the root. This can be used to suppress undesirable project resources. It's not clear how this would supress a module

.recipe.json

Whenever a project file is installed, the plugin registers this somewhere that can be later checked. On subsequent installs, these files won't be re-installed if they exist in this registered location. E.g. .recipe.json file in root.

It could also be JSON content within composer.json

Reference to previously installed recipe

Instead of including the full data of the previously installed recipe, composer.json could just include the name & version (w/ SHA for dev branches) of the recipe, and look up the details during a recipe-upgrade command.

In edge-cases such as tags being edited, this could lead to errors, but these cases are rare and the impact would likely be to reinstall the previously-removed module, which is relatively benign and easily recovered from.

The benefit would be less junk bloating the repository.

Allows a fix for https://github.com/silverstripe/recipe-cms/issues/9

--

Added:

• Tests, travis integration, test namespaces and autoloading
• Added APIs to better facilitate mocking (such as file_exists, file_get_contents, copy, etc)
• Support for recipe files to end in .tmpl so that they don't get picked up by IDEs as first class classes

Overview

I'm having trouble understanding how both the "public" and "mysite" dirs are created when using "type: "silverstripe-recipe" in my project's "composer.json". In lieu of the resolution to silverstripe/silverstripe-framework#7946 the recipe will create a "mysite" dir for me, even if I already have an "app" dir present. The only way to prevent this is to ensure I maintain the relevant entries in composer's "extra" block ala:

   "extra": {
        "project-files-installed": [
            "mysite/.htaccess",
            "mysite/_config.php",
            "mysite/_config/mysite.yml",
            "mysite/code/Page.php",
            "mysite/code/PageController.php"
        ],

...which if I'm not ever intending on using "mysite" - ever - seems a bit wasteful, just to prevent the recipe from creating the dir. Perhaps I'm missing something, otherwise at worst I'd call this a bug and at best, a wee bit of technical debt to have to maintain.

Acceptance Criteria

• As a dev with an app folder upgrading a 3.x install, I don't want to deal with recipe internals in order to stop it from copying files into the wrong place on any composer update call
• If I have an app folder, any default files located in mysite of the recipe-core will be placed in the same directory structure in app

Notes

• We'll be using app going forward (most likely in 4.2) anyway
• The upgrader notes if there's no app folder, separate issue
• Assumption: Does not rely on shifting composer metadata into a recipe.lock file

Trying to install using Composer 2 fails as the plugin version needs to be updated to 2.0 - you can see the requirements here: https://github.com/composer/composer/blob/master/UPGRADE-2.0.md#user-content-for-integrators-and-plugin-authors

Output from user on Slack:

:~/httpdocs$ composer update
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.
 Problem 1
  - silverstripe/recipe-plugin 0.1.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - silverstripe/recipe-plugin 0.2.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - silverstripe/recipe-plugin 1.0.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - silverstripe/recipe-plugin 1.1.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - silverstripe/recipe-plugin 1.2.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - silverstripe/recipe-plugin 1.3.0 requires composer-plugin-api ^1.1 -> found composer-plugin-api[2.0.0] but it does not match your constraint.
  - Root composer.json requires silverstripe/recipe-plugin @stable -> satisfiable by silverstripe/recipe-plugin[1.3.0, 1.2.0, 1.1.0, 1.0.0, 0.2.0, 0.1.0].
You are using a snapshot build of Composer 2, which some of your plugins seem to be incompatible with. Make sure you update your plugins or report an issue to them to ask them to support Composer 2. To work around this you can run Composer with --ignore-platform-reqs, but this will also ignore your PHP version and may result in bigger problems down the line.

Shouldn't be too difficult of a change but will need to be done before Composer 2 is widely adopted

Pulls request

• [x] https://github.com/silverstripe/recipe-plugin/pull/16
• [x] https://github.com/silverstripe/vendor-plugin/pull/36

Issue https://github.com/silverstripe/gha-ci/issues/11

Workflow run https://github.com/creative-commoners/recipe-plugin/actions?query=branch%3Apulls%2F1.7%2Fmodule-standards

Composer 2.3.2 was released yesterday. Ever since composer vendor-expose fails:

> composer vendor-expose
PHP Fatal error:  Declaration of Composer\Command\BaseCommand::getComposer(bool $required = true, ?bool $disablePlugins = NULL, ?bool $disableScripts = NULL) must be compatible with SilverStripe\RecipePlugin\RecipeCommandBehaviour::getComposer($required = true, $disablePlugins = NULL) in /home/tim/Sites/scratch-silverstripe/vendor/silverstripe/recipe-plugin/src/RequireRecipeCommand.php on line 73

Fatal error: Declaration of Composer\Command\BaseCommand::getComposer(bool $required = true, ?bool $disablePlugins = NULL, ?bool $disableScripts = NULL) must be compatible with SilverStripe\RecipePlugin\RecipeCommandBehaviour::getComposer($required = true, $disablePlugins = NULL) in /home/tim/Sites/scratch-silverstripe/vendor/silverstripe/recipe-plugin/src/RequireRecipeCommand.php on line 73

Downgrading to Composer 2.2.10 works. This is with vendor-plugin 1.5.2

This is on a scratch SS site with a small composer.json:

{
    "name": "silverstripe/installer",
    "type": "silverstripe-recipe",
    "description": "The SilverStripe Framework Installer",
    "require": {
        "php": "^7.3 || ^8.0",
        "silverstripe/recipe-plugin": "^1.2",
        "silverstripe/recipe-cms": "~4.10.0@stable",
        "silverstripe-themes/simple": "~3.2.0",
        "silverstripe/login-forms": "~4.6.0@stable"
    },
    "require-dev": {
        "phpunit/phpunit": "^9.5",
        "silverstripe/behat-extension": "^4.8"
    },
    "extra": {
        "resources-dir": "_resources",
        "project-files-installed": [
            "app/.htaccess",
            "app/_config.php",
            "app/_config/mimevalidator.yml",
            "app/_config/mysite.yml",
            "app/src/Page.php",
            "app/src/PageController.php"
        ],
        "public-files-installed": [
            ".htaccess",
            "index.php",
            "web.config"
        ]
    },
    "config": {
        "process-timeout": 600,
        "allow-plugins": {
            "composer/installers": true,
            "silverstripe/recipe-plugin": true,
            "silverstripe/vendor-plugin": true
        }
    },
    "prefer-stable": true,
    "minimum-stability": "dev"
}

If you have installed both userforms and elemental, then you will likely want to install dnadesign/silverstripe-elemental-userforms. It would be nice to automated this in a recipe.

Suggested syntax is a "extra.require-optional" config option:

{
    "name": "silverstripe/recipe-content-blocks",
    "type": "silverstripe-recipe",
    "require": {
        "silverstripe/elemental-blocks": "1.0.x-dev"
    },
    "extra": {
        "require-optional": {
          "dnadesign/silverstripe-elemental-userforms:^1": {
            "if-installed": [ "silverstripe/userforms:*" ],
           }
        }
    }
}

A few notes:

• the keys are package:constraint pairs, this would let you optionally install different versions based on different conditions
• The if-installed checks are package:constraint pairs for different reasons
• if-not-installed would be another option.
• As well as package constraints you could use php & php-extension checks as composer currently does. This might be an add-on for later.
• I'm not sure if there are other options that could be added.

Implementation implications:

• It would require that there's a couple of passes over the dependency resolver. This, btw, is one reason why composer have never added such functionality themselves.

Sometimes you need to remove the recipe configuration for more control over your dependency set.

This is a pretty slimmed down version of what is available with Symfony - http://fabien.potencier.org/symfony4-unpack-the-packs.html

I took most of the code directly from Flex, so have included a link to their LICENSE file in the readme.

Please leave peer review comments on the module here.

Link back to main issue: https://github.com/silverstripe/silverstripe-framework/issues/6860

You can test using the following recipes:

• tractorcow/recipe-core
• tractorcow/recipe-cms

Note that until we move this to silverstripe org, the plugin is tractorcow/recipe-plugin, although the docs are written with the final name in mind. :)

Caught this on a deployment to one of our platforms, even though no changes were made, the file was still read into memory and rewritten. Unfortunately, that triggered this issue: https://github.com/composer/composer/issues/9515 with an empty "scripts": {} key being rewritten to "scripts": []

This doesn't totally fix it but it does prevent a few unnecessary writes and saves the day in that one use-case

The public/ directory is mandatory in CMS 5 (some of the functionality had already been explicitly deprecated in CMS 4 and so it has been removed in CMS 5) - but if the public/ dir didn't exist yet, this plugin was still putting files from extra.public-files in composer.json of recipes into the project root. This has been causing our behat tests to fail in CI for most modules.

Note

Any deprecations required in CMS 4 or updates to documentation will be done separately - the primary purpose of this PR is to get builds passing again.

Related RFC

https://github.com/silverstripe/silverstripe-framework/issues/8168

Parent Issue

• https://github.com/silverstripeltd/product-issues/issues/642

See: #21

This is a parent issue to warn against including an empty object tag in your composer.json - because if it gets overwritten it will be written back with an empty array instead, causing composer validate and other checks like that to fail.

Covered here: https://github.com/composer/composer/issues/9515 by composer themselves.

I have a situation where I have two recipe dependencies which both have the same project file:

• silverstripe/recipe-core: app/_config.php
• cwp/cwp-recipe-core: app/_config.php

Because app/_config.php from silverstripe/recipe-core is run before pretty much anything else (as a close-to-root dependency), it takes the project file from there and copies it into my project. Subsequent recipes such as cwp/cwp-recipe-core cannot copy their own file after this, because they get ignore as "existing or modified in project."

The problem in this example is really that the file contains password complexity requirements, and because they are then copied into user code they will take priority over everything else. CWP needs to increase the minimum requirements but it can't do so at the moment.

Let's say you create a file under app/css/bob.css and update your project composer.json file like this:

{
"extra": {
        "expose": [
            "app/css"
        ]
    }
}

If you run a composer vendor-expose, bob.css and the css will be deleted and a new app/css symlink will be created. That symlink will point to a broken ../../../app/css location.

Super minor, but it might look a bit nicer if the output of the recipe plugin/vendor plugins were indented further than they are to form more of a tree

If you install a recipe, your composer set up will be invalid.

Step to reproduce

1. Create a new directory.
2. Save the sample composer.json in your new directory.
3. Require recipe-cms: composer require silverstripe/recipe-cms
4. The command will complete successfully.
5. Run a composer validate.
6. The command will complain that The lock file is not up to date with the latest changes in composer.json, it is recommended that you run composer update.

Expected results: A successful composer require on a valid composer.json should leave you in a valid state.

Sample composer.json file

{
    "name": "maxime/composer-test",
    "description": "foobar",
    "type": "project",
    "license": "mit",
    "authors": [
        {
            "name": "Maxime Rainville",
            "email": "[email protected]"
        }
    ],
    "minimum-stability": "dev",
    "require": {}
}

Underlying cause of problem

composer.lock contains an hash calculated from a few values contained composer.json. The problem is that installing recipes will add new properties to the extra object in composer.json after the composer.lock hash has been generated.

There's an easy workaround ... which is to just run a composer update ... but it's kind of an annoyance for the silverstripe upgrader.