Factor our core, account and admin as independent sprinkles

[lcharette]

Since 4.1, sprinkles can be loaded dynamically using Composer. I think it would be best if the core, account and admin sprinkles would be factored out of the main repo and into their own repo. They would instead be installed when running composer install.

(Tagging this with the 5.0 since it would be major change)

Pros

• Ability to make a community sprinkle depend on particular core version directly in a composer file (Linked to Autogenerate sprinkles.json  #747)
• Smaller base framework to download.
• Easier upgrades, as the base framework is unlikely to change as often as the sprinkles. Core, admin and account updates are handled by Composer.
• Install steps remain unchanged (Git clone + composer install).
• Easier to remove unwanted default sprinkle (just change the composer file).

Con

• More complex setup for developing and testing. This can be mitigated by using a framework repo with everything inside and have secondary automated, read-only repos, linked to packagist (The same method Laravel uses with individual repos for each Illuminate package).

[alexweissman]

framework repo with everything inside

This actually reminds me, we could even consider having a "distribution" repository, with Composer and Bower/Yarn dependencies pre-installed as well 😲

[Silic0nS0ldier]

@alexweissman Don't follow what you mean by a "distribution" repo. Do you mean like a quick start project? Wherein the user gets a working site to start off with, get a feel for everything, etc?

[alexweissman]

@Silic0nS0ldier I was just thinking, more of a pre-compiled version of UF with everything already installed. The idea would be that they can play with it locally before they've even installed Composer, npm, etc.

[Silic0nS0ldier]

So basically what I said a month ago.

[lcharette]

In regards to recent discussion on the chat, the current plan would be to move forward with this project sonner than expected. It would make it easier to maintain stuff in the long term and allow for other improvements, like the Vue.js integration.

Current plan is to not only move sprinkles into separate repos managed by composer, but also refactor whats inside each sprinkle. The ultimate gold is to be able to easily deploy an instance of UF with only the core sprinkle, but also switch out the base HTML & jQuery frontend for a Vue.js one. So we should move eveything we can into their respective sprinkle : core, user, admin & frontend.

frontend would be the sprinkle responsible for non-admin pages and also include shared JS (Jquery) components (UfForm, Sprunje JS, etc) between normal pages and admin pages.

frontend and admin could then be replaced with a vue.js based frontend inside it's own admin-vue sprinkle.

A default install should also include a site sprinkle containing the default homepage. This would be intended to be the base for the first sprinkle a new user create.

One thing that remains to determine is how should we handle the composer.lock file, as it's should be managed by git or at least on a deployment level. Currently, Composer only supports one lock file that sits in the main repo code.

Finally, I believe core sprinkle should be left out of the "main" UF repo and loaded by composer. While it doesn't change anything if it's in the base repo, I believe it would make it easier to manage composer dependencies and also updates to the core core.

[Silic0nS0ldier]

It is a bit of a misnomer the core sprinkle currently. A default site sprinkle should clear that up.

As for composer.lock, idk... Its tough to commit either way because of how a UserFrosting 'project' is structured and updated. The way everything works right now is fine if you want to take the UF source and modify it to your hearts content (not that to my knowledge anyone is doing that).

Think there are a few other issues that each weigh in on this in some shape or form. #863 #836 #831

[lcharette]

For reference, in Laravel, your own code sits in the base repo. You basically commits the whole "base" code (aka laravel/laravel) to your own repo. The core Laravel code is in laravel/framework, managed by composer, but any update to the base laravel code is done manually.

I don't think this is something we want to do, but it could be something someone might want to do if his deploy procedure requires it. Having core as a separate repo helps the dev to make his own choices.

[lcharette]

Following the userfrosting/support release incident, I still think the distribution of the sprinkles should be done in separate repo / composer package for easier management. However, I do think now that it would be easier to have everything, including the UF support repos, in the same GitHub repository. Individual packages (sprinkles and support components) could then be distributed in read-only, automated sub tree split.

This is what Laravel does with the laravel/framework packages, distributed as Illuminate/* individual component.

Having one (dev) repo to rule them all would make testing each individual component harder, but release much more easier. It would also make dependencies across repo easier during development. Currently, I can't properly test a new feature in URI dev-develop-windows branch with the main UF repos, as changing the dependency for this branch in the main repo will cause a composer conflict with userfrosting/assets.

[Silic0nS0ldier]

Composer conflict would be due to a misconfiguration. That said, the experience in developing features/fixes/whatever that involve a library does need improvement. Especially if it involves an indirect dependency that needs to be developed.

I've got my own opinions regarding the way the project should be organised (which improved unit testing would make viable), but outside of that I believe that 90% of the work in the release process can be automated regardless of how things are organised.

[lcharette]

 Composer conflict would be due to a misconfiguration.

Of our composer dependencies?

They all required UF/URI ^4.2.0, and if one ask for dev-develop, it fails because it can't respect the minimum stability. It's more of composer and/or merge plugin limitation.

[Silic0nS0ldier]

The minimum stability you referenced there was for dev (allowing it). That said, the merge plugin is worth considering for whatever solution I try to come up with.

[Silic0nS0ldier]

In case I forget, my current idea for handling developmental dependencies is by using another composer.json file. Just need to figure out how it would be best achieved. Composer allows custom file names via COMPOSER environment variable, but the merge plugin could give us another option potentially.