Create a source plugin that scans for locally installed recipes

🤩🤓

@srishtiiee had asked me in Slack:

I need some directions over evaluating the compatibility of a recipe with the site, do you have any thoughts over it? Do we need to check the compatibility of all its dependencies?

That's a really good question.

My feeling at this stage of things is that we should assume recipes are compatible if their composer.json says they are. I see that the source plugin we're building here, as it currently exists, asks for data on each individual recipe -- that's good!

To be compatible, maybe a recipe should:

• Declare a dependency (in its composer.json's require section) on drupal/core or drupal/core-recommended
• That requirement must satisfy (according to semver) the current version of Drupal core. So something like this (psuedocode):
  

  if (\Composer\Semver\Semver::satisfies($core_version_required, \Drupal::VERSION)) {
    $recipe_is_compatible = TRUE;
  }
  

I'm sure we'll refine this later on, when drupal.org properly exposes recipes. But given the limited information we can get from Packagist, this might be a reasonable approach in the meantime.

That's a random test fail, marking NR anyways.

Addressed feedback, setting back to NR.

I think this is a fantastic start, and quite straightforward and generally easy to understand. There are some spots where it needs to be more robust and better-documented, and we need to expand the test coverage somewhat, but I think this is a very strong foundation upon which to iterate. Nice job, @srishtiiee!

Addressed the feedback, setting back to NR

This looks really good to me. Most of my remaining feedback is quite minor!

@phenaproxima, thanks for the review! I've addressed it and the MR needs another review.

Few nits, but otherwise I don't see any reason to hold this up!

This will probably need some changes now that ✨ Remove as many getters and setters as possible from the Project class, in favor of public, typed properties Fixed landed.

Can we get some screenshots in the issue summary? 😇 Very curious to see what this looks like for end users! 😄

(I would not be a good code reviewer here, because I don't know this codebase at all.)

Thanks for that screenshot, @srishtiiee, it looks good to me! It's a bit sad (and concerning) that none of the recipes in it are compatible -- are we sure that compatibility check is working? At the very least, I've been able to get kanopi/gin-admin-experience to work on Drupal 10.2.x.

Well, I think that looks pretty good, at least from a code perspective!

I need to give it a manual test, but since this is a proof of concept, I think we could call this RTBC. It probably doesn't need to be committed right now, but it could be applied in conjunction with the recipe system (which is a core patch itself). I'll add this to my recipe-test repo, which sets up the recipe system with Project Browser.

After talking to Tim about this, I like the idea that the plugin itself (and test) be provided externally to this project. However, it sounds like we still need/want to move the pagination into the base class.

Can we break out the DrupalCore.php and ProjectBrowserSourceBase.php changes into a separate issue, and I'll merge that one?

There are recipes listed on the Recipes Cookbook → that are posted to drupal.org as module projects, with newer releases reconfigured to be recipes. They don't seem to show up in the packagist.org list. Is that because of the packagist.org integration for drupal.org?

@mandclu. I believe that is because the function is pulling from https://packagist.org/, not https://packages.drupal.org/8

  private function fetchRecipeData() : array {
    $recipes = [];
    try {
      $url = 'https://packagist.org/search.json?type=drupal-recipe';

from: https://git.drupalcode.org/project/project_browser/-/merge_requests/425/...

Also, yes. Only Drupal "general" projects go to Packagist, not module projects.