userfrosting
Autogenerate sprinkles.json
Since all sprinkles should have a composer.json file, it shouldn't be hard to generate the sprinkles.json automatically when running composer update. A previous concerns was the specific order of sprinkles, but since each of those composer file should have dependencies, it shouldn't be harder than ordering the migrations.
The issue here is while a sprinkle can define requirements and load other sprinkles automatically, you still have to add those dependencies to the sprinkles.json.
Related to #728 .
This should probably helps with #597. Since each sprinkles should have a type of userfrosting-sprinkle, themes could/may have userfrosting-theme type.
So I've started doing some research on this. My hopes that we could actually use Composer to manage the sprinkle seams less promising than initially expected, but things might change with Composer 2.0.
One of two ways to address this would be to create a custom script that would generated the sprinkle.json file in the post-update event. The second solution would be to read the vendor/composer/installed.json file and extract the necessary data from there. This second solution sound more promising, and I might still explore it further, but this could end up being more complex and won't solve some issues magically, like sprinkle inheritance. We would still need to implement that logic ourselves.
This is nice, as Composer already know about each package path and namespace already. But at the same time, it means all sprinkles would need to be loaded by composer, which brings it's own complication when setting a simple, "local" sprinkle.
If reading installed.json doesn't plan out, I propose we move the content from app/sprinkles.json to the main composer.json, in the extra field.
Moreover, instead of defining only the sprinkles we want to load by name, we should reference them by a main class. For example :
"extra": {
"installer-name": "userfrosting/core",
"sprinkles": {
"Core" : "UserFrosting\\Sprinkle\\Core\\Core",
"Account" : "UserFrosting\\Sprinkle\\Account\\Account",
"Foo": "UserFrosting\\Sprinkle\\Foo\\Bar"
}
}
Note that location could be attracted from the class (we can use __DIR__ to know where it's located, and can even customize this inside the class) and we can leverage PSR autoloading to avoid having the sprinkles files in a very specific location. They could even be physically located inside /vendor.
This "main class" would be necessary anyway to handle new CI service registration, and to explicitly register migrations, bakery commands, etc. It would also make it simpler to implement sprinkle vendor name (#831). Even when reading the installed.json file, we might end up loading that main class.
As for simple, local sprinkles : assuming Core, Account and Admin are loaded by Composer and not included in the "base" installation (Ref #830), since we don't want to depend on the merge plugin anymore, I believe it makes sense to have their PSR definitions in that main composer.json. In relation to #1095, remember this composer file will live inside our new skeleton package. Might just not play well will installed.json...
Overall, it might make it more difficult to create a CLI command to manage sprinkles (Ref #728 & #729), as we would need to read and write to the main composer.json (inside /) or have a "local" sprinkle managed by composer. But I think it's better at the mininum to be in the composer file instead of a separate sprinkles.json file, as it's something that end developers will need to edit anyway (I think) and it will make it easier in the long run as Composer evolves and add new features.
I should note, installed.json is sorted alphabetically, so it can't be count on for sprinkle inheritance.