Create a source plugin that exposes recipes in the file system

So per our conversations all over the place, this issue gets merged for the RecipeDiscovery class ✨ Expand Drupal\Core\Recipe\RecipeDiscovery to allow discovering available recipes, likely for use in Project Browser Active , we can refactor the fetching of Recipes.

I do think we would also want to then remove/alter the methods getRecipeDescription in favor of just $recipe->description.

As for the project image, we may want to add a method to the Recipe Object itself to fetch the image associated with the recipe instead of putting the logic in here.

Keep this all single purpose to just exposing Discovered Recipes to Project Browser?

We need some tests for this - among other things we need to be able to prevent changes that reintroduce "this is a module" assumptions. The issue that preceded this, 🐛 "View Commands" button assumes project is a DO module (and that a project has commands) Fixed , probably should have had tests but we chose to wait until this issue so the tests were based on an actual plugin (faster to write and more representative of IRL scenarios!)

There's an error occurring in the logs as well, the "Content Type: example" recipe does not have a 'name' property, so logo: $this->getRecipeLogo($path, $recipe['name']) in the plugin is hitting an error with that recipe.

Rebased

No longer blocked by 🐛 "View Commands" button assumes project is a DO module (and that a project has commands) Fixed .

phenaproxima → closed merge request !473

phenaproxima → changed the visibility of the branch 3446257-v2 to hidden.

phenaproxima → changed the visibility of the branch 3446257-v2 to active.

I see you're starting to look at fixing phpstan.neon (and removed).

I would appreciate a look at this ticket to do a clean reset on the phpstan configuration and get to level 1.
https://www.drupal.org/project/project_browser/issues/3453101 📌 phpstan.neon.dist fixes - Get phpstan to level 1 RTBC

I did a test and you have no errors to ignore with the above MR, provided that you also are pinned to minimum drupal 10.3. No need for a baseline file.

Re #20: baseline shmaseline, I just want PHPStan to shut the hell up. I truly dislike it, and find it generally obstructionist and not very useful (although I recognize I'm in the minority). Whatever gets the errors to go away so we can get this merged, I'm happy with. By all means take a crack at that. I RTBCed your other issue.

I'd rather we didn't bump the minimum Drupal version in this issue; it's totally fine to conditionally support recipes if they're available (as you can see, it works perfectly well); but that's a decision for the maintainers. It would certainly allow me to simplify the code a little bit.

Happy to change that if you feel strongly about it, though.

No strong opinion, it's just a pattern I haven't seen. The DX reviewer in me got stuck on this part of the code.

By all means take a crack at that. I RTBCed your other issue.

Yeah I'm happy to do that! I learn a lot from doing phpstan and like trying to make the config feel nice and well documented.

So at the moment it PHPStan will fail on Drupal 10.2 because Recipe.php doesn't exist, I know how to fix this, will wait for linked 📌 phpstan.neon.dist fixes - Get phpstan to level 1 RTBC (thanks for the review!

Postponing on 📌 phpstan.neon.dist fixes - Get phpstan to level 1 RTBC .

I realized I still need to work on this, to get the manual terminal commands working properly.

On second thought, adding support for the commands, properly, is very complicated and runs into the assumption that everything is a friggin' module. This will take some more deep work to sort out, and this MR is complex enough as it is.

@immaculatexavier, I'm not sure you tested that, because:

a) Your commit didn't change the compiled JS bundle;
b) and, if it had, many tests would have started failing, because the isPackageManagerRequired stuff that your change restored, was completely ripped out of the backend and frontend by my previous changes, for good reason.

Therefore, I reverted the change. This is probably ready to go as-is; the categories thing is most likely out of scope here.

I'm psyched about this, the code is tight!

I'll be proposing some phpstan simplification shortly, low key stuff.

sime → closed merge request !506

I'm just putting some phpstan in a different branch and playing with the best way to cover the Recipe stuff that also works for drupal 10.2. If this gets merged first I will just do a follow up issue.

Small change to phpstan.neon. I would like to keep reportUnmatchedIgnoredErrors: true so that we are warned whenever an ignore is no longer required. I also made the ignores more terse.

Umm, wow. Just wow. 🤩

Automatically closed - issue fixed for 2 weeks with no activity.