Improve DX of project creation

[grasmash]

To generate a new project using Bolt, you must cd into Bolt, run a few commands, and then change directories into your new project directory and run more commands. This is an unfamiliar workflow for most people and therefore confusing.

This thread exists to brainstorm ideas for a better DX.

[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