[RFC][DX] Set of commands & changes to add transparency to Flex #518
Comments
|
I like it :)
With this in mind, I think there are some low hanging fruits already, PRs welcome :) |
|
Excellent idea! 👍 |
|
What about adding an optional To store a local copy of the recipe in our bundles directly In that way, we are not tied to the official/recipes-contrib repo and the internet |
Does this mean we will have inline recipe support? Would solve #206 |
|
@linaori nope, here it's about playing the recipes on a dummy repo where they are all applied, and version the result of this e.g. once a day. This would provide a convenient way to browser recipe effects and their history all in one place. Inline recipes is unrelated to this issue /cc @DylanDelobel too |
|
Very interesting indeed :) can i suggest as well to mark as deprecated packages listed on https://flex.symfony.com ? thank you |
|
apt: |
|
great idea, but could I suggest using another term for the |
|
Another aspect that would make the process more transparent is to know upfront which folders/files will be created when installing. |
|
Great idea, I would also add a command to display the list of command added by Flex like WDYT ? |
|
What about a command like |
|
@xabbuh |
This PR was merged into the 1.5-dev branch. Discussion ---------- Allowing specific recipes to be "re-installed" Hi! Very simple: you can now re-install/update just one (or specific) recipes: ``` composer symfony:sync-recipes symfony/console --force ``` That's very helpful, as there are a few specific recipes (this is one of them) that really *do* need to be "updated", at the very least, when upgrading to Symfony 5 (as some important files have evolved over time). This relates to #575 (will help with upgrading), #518 and should go along with the PRs #562 and #565 Thanks! Commits ------- a9dad87 Allowing specific recipes to be "re-installed"
This PR was squashed before being merged into the 1.5-dev branch. Discussion ---------- [DX] Command to list all available recipes First step of #518, the command `symfony:recipes:show` and alias `symfony:recipes` Result : <img width="701" alt="Capture d’écran 2019-09-18 à 15 46 09" src="https://user-images.githubusercontent.com/12966574/70814407-b4f8eb00-1dcb-11ea-9118-454d444cd22d.png"> I need feedback on the disposition and maybe i can add the version of the recipe installed like - doctrine/annontations 1.0 Tell me what you think :) Note: the last section is currently commented out, and will be added later Commits ------- f73fba0 [DX] Command to list all available recipes
This PR was merged into the 1.8-dev branch. Discussion ---------- Improve discoverability of 'composer recipes' Discovering the `composer recipes` command during composer install/update Fix issue #629 and move forward #518 - 8)  Commits ------- eae35f1 Improve discoverability of 'composer recipes'
|
Closing as this is not actionable enough and things have changed since 2019. |
Uh oh!
There was an error while loading. Please reload this page.
Hi friends!
I ❤️the recipe system. The idea of having packages auto-configure and scaffold themselves is the best. However, after a few recent conversations, I think Flex & the recipe system is a bit "murky" to people:
symfony:sync-recipescommand. Rather, the installation of recipes feels like a "magic" thing that happens once, and can never be repeated afterwards.This is a big RFC to make numerous, minor changes to help make this experience more transparent and user-friendly:
1)
symfony:recipesDONE! ✅This command would simply list all of the installed recipes, probably only listing those that actually had a recipe (not a full list of what's in symfony.lock). Ideally, it would also show you if updates are available:
2)
symfony:recipes:installDONE! ✅This would simply be a rename of
symfony:sync-recipes. It's "installing" recipes, so i think it makes more sense.3) symfony:recipe:update
This would effectively be an alias for the current
symfony:sync-recipes --force. The name "update" is more revealing to what it does. However, because it's not a real "merge/update", we'll of course still have output that describes what happened and how to proceed, etc.Additionally, it will now accept the package name(s) that should be updated:
When using this option, I think we should also print a list of the PR's that updated the recipes, for each updated library:
4)
symfony:recipes <package/name>DONE! ✅Usage:
composer symfony:recipes symfony/framework-bundleThis would simply tell you what version you have installed, where to view that recipe (URL on GitHub), and any updates available. It's a nice way to see what might be updated before actually running
symfony:recipe:update.This might also print a "tree" of what files this recipe added/updated, with a message to run
symfony:recipe:blameto see this for all recipes:5) Commit the recipes to the skeletons
This is an idea by Nicolas. The problem is that it's very difficult to see the files of a recipe - you need to know which directory/version to navigate into, and they're not versioned in a traditional way. One way to solve this for the most important recipes is to commit them to symfony/skeleton & symfony/website-skeleton. This is mostly easy, though there is one technical "thing" to fix, which would be to make sure the symfony/framework-bundle post-install message still shows up (even though the recipe was previously installed).
6) Mention
symfony:recipes:installwhile installing recipesWhen a recipe is being installed (e.g. after
composer require), the messaging currently looks like this:Instead, let's make it more obvious that what's really happening is really
that a command is being run (well, internally, we're not calling the command,
but calling the command would have the same effect). This removes some of the
Flex mystery, and helps discover other Flex command:
7) symfony:recipe:blame to show source of files
To answer the question: what recipe did this file come from? We could have
a
symfony:recipe:blamecommand, without output something like this:8) Discovering outdated recipes/other commands
This is all meaningless unless the user is able to easily discover these commands. To help with that, I propose 2 things:
A) During a composer update/composer require, check for any outdated recipes and
print a message if there are any.
B) During a composer install, always show a little message:
The text was updated successfully, but these errors were encountered: