Replace `vendor/bin/bref init` with `composer create-project`

[mnapoli]

Frameworks (Laravel, Symfony…) offer a way to create a new project with composer create-project, e.g. for Laravel:

composer create-project laravel/laravel example-app

This is great because its requires everything and sets up the project in one step.

Our "First steps" docs (when not using a framework) contain more steps:

1. create an empty directory
2. run composer require bref/bref
3. run vendor/bin/bref init
4. select what you want to create

We could have one command instead, for example:

composer create-project bref/start
# creates a new HTTP Bref app (like "bref init" today)

composer create-project bref/start-laravel
# creates a new laravel app preconfigured and ready to deploy 🤩

composer create-project bref/start-symfony
# creates a new symfony app preconfigured and ready to deploy 🤩

# etc.

WDYT? Anyone up for contributing this?

[clement-michelet]

I like it, it's more straight forward and it stick to the ecosystem.

However, I would use more meaningful skeleton names like bref/web-laravel, bref/web-symfony, bref/console, bref/event-driven as they are showed in the documentation.

[mnapoli]

I wonder if it's possible to have a single repository (to avoid maintaining too many). But if not, yeah I agree with you @clement-michelet we would need one per "use case" (web, console, etc.)

I just want a prefix/name that suggests explicitly it's not a library/package. bref/start- is short and sweet, maybe a bit confusing indeed. bref/skeleton- is long and boring 😅

[martindanielsson]

I like it, it's more straight forward and it stick to the ecosystem.

However, I would use more meaningful skeleton names like bref/web-laravel, bref/web-symfony, bref/console, bref/event-driven as they are showed in the documentation.

I think this makes sense, and the composer package itself will be tagged as a template so I don't think it should be any issues with people misunderstanding what it is for :)

[clement-michelet]

You can have a mono-repo for all the skeleton packages and publish them as separate packages as usual.

For the prefix, you can prefix if you want 😉 My point was more about having the type of application to deploy (event-driven or web). The distinction between package/lib and template is already made by tagging it as "project" which will be displayed with the create-project command in packagist.