Just a collection of questions and answers from Slack.
Just a collection of questions and answers.
### How can I get this cool module added to Drupal CMS?
[Open a feature request](https://www.drupal.org/node/add/project-issue/drupal_cms) and explain what the module does and why it would benefit Drupal CMS. Don't be afraid to get detailed, but **don't **make a merge request yet.
Drupal CMS's development, which includes decisions about which modules it should include, is guided by the product owner and UX lead (see [MAINTAINERS.txt](https://git.drupalcode.org/project/drupal_cms/-/blob/2.x/MAINTAINERS.txt?ref_type=heads)). If the product owner agrees that your module should be in Drupal CMS, it will be added. If you want to discuss it with them in real time, the correct place to do that is the `#drupal-cms-development` channel on Drupal Slack.
Once the product leadership signs off, getting the module into Drupal CMS falls to the technical leads, who will work closely with you to get everything ready, tested, merged, and released.
### **Why aren't sub-recipes supported?**
**Why aren't sub-recipes supported?**
There are a few reasons:
There are a few reasons:
1. Extensions containing other extensions (like the way modules can contain other modules) is a historical Drupalism that has caused a lot of pain and workarounds. It's the whole reason why `packages.drupal.org` needs to exist. When designing the recipe system, we decided NOT to double down on this legacy decision, because we didn't think it brought enough benefit to be worthwhile.
1. Extensions containing other extensions (like the way modules can contain other modules) is a historical Drupalism that has caused a lot of pain and workarounds. It's the whole reason why `packages.drupal.org` needs to exist. When designing the recipe system, we decided NOT to double down on this legacy decision, because we didn't think it brought enough benefit to be worthwhile.
2. If you want to _ship_ multiple recipes as a single package, Composer already supports metapackages, which are packages that provide no code of their own, but only exist to bring in other packages. Examples are `drupal/core-recommended` and `drupal/core-dev`. You could create a metapackage that brings in a set of smaller recipes.
2. If you want to _ship_ multiple recipes as a single package, Composer already supports metapackages, which are packages that provide no code of their own, but only exist to bring in other packages. Examples are `drupal/core-recommended` and `drupal/core-dev`. You could create a metapackage that brings in a set of smaller recipes.
3. Disambiguation. In `recipe.yml`, you refer to other recipes by the name of their directory, if you have `recipes/foo/content_editor_role` and `recipes/baz/content_editor_role`, and a recipe refers to just `content_editor_role`, which one will be applied? Sure, you could solve this by prefixing the listed recipes like `foo/content_editor_role`, but that writes a license for recipes to contain other recipes, which we specifically decided was undesirable, as outlined in point #1. An exception was carved out for Drupal core, which already does weirdo things, so it and only it is allowed to use prefixing. That's why core recipes are prefixed with `core/recipes`.
3. Disambiguation. In `recipe.yml`, you refer to other recipes by the name of their directory, if you have `recipes/foo/content_editor_role` and `recipes/baz/content_editor_role`, and a recipe refers to just `content_editor_role`, which one will be applied? Sure, you could solve this by prefixing the listed recipes like `foo/content_editor_role`, but that writes a license for recipes to contain other recipes, which we specifically decided was undesirable, as outlined in point #1. An exception was carved out for Drupal core, which already does weirdo things, so it and only it is allowed to use prefixing. That's why core recipes are prefixed with `core/recipes`.
4. If you want to be able to develop multiple recipes in a single repository, you could do what Drupal CMS does and develop your recipes in a monorepo, splitting them out separately with an automated subtree split. Symfony is also developed this way, and even core uses subtree splitting for certain things.
4. If you want to be able to develop multiple recipes in a single repository, you could do what Drupal CMS does and develop your recipes in a monorepo, splitting them out separately with an automated subtree split. Symfony is also developed this way, and even core uses subtree splitting for certain things.
5. This is not a closed door; it's not a priority on the recipe system's roadmap, but we might well wish to explore the idea of "cookbooks" (groups of recipes in a single namespace). So although sub-recipes are unlikely to be supported the same way modules support sub-modules, there may be some flexibility to be had here.
5. This is not a closed door; it's not a priority on the recipe system's roadmap, but we might well wish to explore the idea of "cookbooks" (groups of recipes in a single namespace). So although sub-recipes are unlikely to be supported the same way modules support sub-modules, there may be some flexibility to be had here.
#### What happens if Drupal core rolls a security release?
**How can I test Drupal CMS locally with Drupal Core's HEAD?**
Drupal CMS doesn't pin any of its dependencies, so people using Drupal CMS will...be able to safely update Drupal core as per usual. It is generally a good idea for us to bump our version
\ No newline at end of file
Edit `project_template/composer.json`, find the `require` section and replace `drupal/core-*` with:
```
"drupal/core-composer-scaffold": "11.x-dev@dev",
"drupal/core-project-message": "11.x-dev@dev",
"drupal/core-recommended": "11.x-dev@dev",
```
Edit `dev.composer.json`, find the `require-dev` section and replace `drupal/core-dev` with:
