[Docs] Document CLI Recipes

Recipes Documentation

• What is the motivation / use case for changing the behavior?

Many of the issues that arise for the CLI project are actually questions about implementation disguised as bugs. To help with this, a proposed “Recipes” section is being created.
“Recipes” are quick examples of how to accomplish a specific task, with code examples included. For example, a recipe might contain how to configure the CLI to use Electron, or how to get the tests to run off of source code instead of the bundled code.

Use this issue to discuss what kinds of recipes should be added, and which ones will be most helpful.

Note: Some of the suggestions may be combined, broken out, or moved to a different location (and some of them are features not yet implemented). This is just an initial location to gather ideas.

Recipes to add

• Create an “export” task
• Test Driven Development (how to configure)
• Generate external loader config file
• Enable BrowserSync to proxy a backend server (multiple variations)
• Change RequireJS baseURL location
• Change the output directory of a build
• Add a clean task to clean up old builds
• Adding css plugins
• Manual bootstrapping
• Configuring shorthand paths
• Setting up complicated bundle dependencies
• Copy source files to build directory (without transpiling)
• Setup HTTPS (link)

[EisenbergEffect]

It might be appropriate to just have a Recipes section of the docs. Then under that we can have cli, binding, components, etc. Each one of those can be an article with a collection of recipes we can show in the sidebar.

[EisenbergEffect]

Everything related to updating would happen through npm. The Aurelia CLI doesn’t have anything to do with that. So, the same practices for updating any npm library would apply to all Aurelia libraries, including the CLI itself. The only difference for the CLI is that there is a globally installed version of it and a locally installed version. The global version creates new projects and then it proxies all other commands through to the locally installed version. That allows you to control your tools versions on a per-project basis.