- 🇺🇸United States thejimbirch Cape Cod, Massachusetts
@drumm stated in Slack:
I’d like to see the UX ideas for browsing & installing recipes before even thinking about which content type they might be or anything else technical.
- Status changed to Postponed
7 months ago 10:03am 14 May 2024 - Status changed to Closed: works as designed
2 months ago 5:06pm 11 October 2024 - 🇺🇸United States drumm NY, US
Since projects are increasingly changing types, and can have different types in different releases, separate project types are becoming problematic. These “project” types are really release types.
With ✨ Add composer release type field Active , we now store the
type
from a project’scomposer.json
. So we can query for all projects that have a release with acomposer.json
containing"type": "drupal-recipe"
Recipe projects do need to be created as General Projects, that is the only content type with Packagist.org integration. The Packages.Drupal.org integration for modules & themes is specifically for handling Drupalisms, like submodules &
.info.yml
dependencies. Packages.Drupal.org hard-codes advertising modules as"type": "drupal-module"
.As far as I’m aware, Packagist.org and Packages.Drupal.org can’t share distribution of metadata for a single package, with the module releases coming from packages.drupal.org and usual Composer-compatible releases coming from Packagist.org. So changing the project type of a module will still need to be considered on a case-by-case basis. Creating a new project instead of replacing an existing module’s codebase is much better.