Improve DX of project creation about blt

[grasmash]

A few ideas:

• Create a acquia/bolt-project project in addition to acquia/bolt. This will serve the same purpose that acquia/lightning-project does for acquia/lightning.
• Provide instructions that allow a command to be run above Bolt repo root. E.g., composer install -g acquia/bolt && bolt create [-(all the needed config flags)] [name of target build directory].

[CashWilliams]

I think we should label this as a nice to have, and not consider if a blocker for any releases or anything. My current ideas are reflected in Matt's comment above.

[grasmash]

Another thought.

• Re-structure Bolt by moving template/* to the project root.
• Rely on composer create-project acquia/bolt:8.x new-project to generate a new project
• Once in new-project, configure project.yml, local.settings.php, and local.drushrc.php
• In new-project use a new command like bolt init command do initial project setup tasks, like token replacement.

[damontgomery]

I personally find the *-project pattern confusing and unintuitive for new users.

I think the two main benefits of bolt the way it is are,

• Single place to configure a few files such as local settings.php
• Creation of a separate git repo

The most straight forward approach may be to have a single Bolt repo which is cloned at one time and an initialize command run which moves the settings files to their permanent location, deletes the local .git/ folder, makes a new repo, etc.

Challenges

• The git repo restarting is a bit weird
• The process isn't very repeatable unless you leave copies of those settings files in root, which is likely confusing
• Bolt tests need to be updated since they are only valid during initial creation of project

Benefits

• One repo for Bolt
• Bolt isn't creating things outside it's own folder (domain)
• Doesn't work well with the composer situation above?

Composer Option
Add bolt as a require-dev on a project, then bolt moves all the project stuff into it's parent (the project root).

Challenges

• A lot of pieces of Bolt would need to be refactored if all the bolt pieces are intended to be run from a vendor folder
• If Bolt is in the vendor folder, custom tasks would be a bit more difficult to manage
• If Bolt just does the copy once, you are constantly downloading a dev dependency that is pretty much useless
• Bolt would re-write the composer.json file that installed it, which is a bit weird.

Benefits

• One directory
• One git repo

[thom8]

Here's a simple Yeoman generator which helps DX

https://github.com/thom8/generator-blt

Once installed you just run yo blt and it will..

• Prompt for Project name, domain, db config etc
• Clone the blt repo
• Adds the generated template files
• runs composer install in blt repo
• runs ./blt create
• then removes the temp blt repo (optional)

You end up with a new project in the CWD

Unfortunately, it requires npm but aren't we getting off the island in D8?

Although it can also be wrapped up into a self contained desktop app -- https://github.com/yeoman/yeoman-app

[CashWilliams]

I'm not a fan of npm, but most of the sites I work one require it to run some theme based commands (less, gulp, etc) so I think it is worth investigation. I've also never used Yeoman myself, but I know a few people who can't live without it.

I think this is a valid approach to the problem and worth a look.

[thom8]

BTW I'm only cloning here as I don't want to manage a fork but the "template" could potentially be bundled into the node module and would be generated directly to the filesystem without needing to clone and run ./blt create

[grasmash]

This is being addressed in #213