Create a wizard that steps through the Aurelia file, allowing the developers to update it from the command line.

Similar to npm init.

Usage:

$ aurelia plugin -l (or --list)

Display a list of all installed plugins.

Once @PWKad merges his plugin command, Allow the command to install into the .aurelia directory.

Create API/ gulp tasks for watching this directory and moving changes to jspm_packages

Add a prompt to the command chain for commander js.

Add prompt to program.Command.prototype

Add program.Command.prototype._action = program.Command.prototype.action.

Re-write Commander.action() to call the prompts on load.

Once prompts are finished, Then call Commander._action()

Create tests for this functionality.

http://slushjs.github.io/#/

Let's create a logger that output messages to the console with nice prefixes.

The following prefixes are some examples that may be necessary.

[aurelia]:
[aurelia] [Error]:
[aurelia] [Success]:

Colors:
aurelia -> magenta
Error -> red
Success -> green

When init --env is executed, it will install a new project. We need to first check if a project already exists. Then prompt the developer on whether he would like to install a project or not.

One area that most yeoman scaffolding tools don't support is the creation of a Module. They all scaffold a SPA structure ...

But what if you have multiple projects. And you want to create a library (module), which is not a SPA, but instead it can be imported into SPA's to provide functionality. You'd want to share this amongst multiple projects ? You'd want it to be scaffolded in a special manner. And you'd want it to be ready to be linked locally or added to some sort of (ideally private) repository that you can then import it from into your application.

The project structure and packaging would differ from a normal SPA, things like index.html should not be packaged in the dist.

seems the latest fix to how Command loads the necessary command files has introduced execution errors with the init phase commands new and init. @joelcoxokc guess we should revert to first check for the folder/index.js file and then afterwards try to find the file. If both fail then throw the error.

Create tests for the executable command bundle

Create tests for the executable command generate.

Create a service for handling logs and errors when user exits or aborts.

I would like to refactor the CLI.

I am going to remove LyftOff... as this is now becoming useless. LyftOff also creates issues with the environment, when trying to create an external API.

This is another solution to #8 Usually when creating CLI tools I find it a best practice to have a directory named cmd/ or commands/ this directory contains the logic for each command.

What is the benefit of separating the commands into separate directories??

It keeps the machine from having to load unnecessary logic, and speeds up execution time.

I am going to go ahead an create a directory named commands and place existing command logic in it's relative file.

Thanks guys!!! :)

Regardless of the command executed, we see a 700ms lag, before the command is actually executed. This is due to the amount of logic being ran on execution. This can be eliminated one of two ways.

1: Remove the Commander module.

2: Create conditions, allowing commands to be created on runtime based on process.argv

For a quick fix, I say we make the conditions, and only create the commands if necessary. For Example

If process.argv only contains ['new']

Then we should not create the commands bundle, help, plugin and so forth.
However, because these commands contain the their descriptions, when the help command is executed, we should then create all commands.

Once we eliminate Commander.js we will be able to be more flexible with what logic is being required at run time.

Create a command to set up a project environment that includes custom plugin repos and templates for generating code.

The Environment Architecture

cwd/
    plugins/
        # contains plugin repositories
    templates/
        # Contains custom templates for generating your own code
    project/
        # Contains the project repository

    # the configuration file that contains the environmental settings.
    # this config file could go in the projects ConfgiFile 
    .aurelia-config.json 

Running aurelia after a fresh install via npm install -g aurelia-cli results in env: node\r: No such file or directory due to being saved with CRLF:

cat -ev `which aurelia`

#!/usr/bin/env node^M$
...

OSX 10.10.3
node -v v0.12.2
npm -v 2.7.6
npm -g list | grep aurelia [email protected]

I think the Aureliafile.js should become Aureliafile.json and then it would be less of a learning curve as it would encourage future development to ensure the Aureliafile remains of simple concerns and doesn't do any part of the running of bundling, searching, installing, or anything else. I like the idea of ensuring this separation of concerns. This would be an enhancement I believe to the current code base.

I copied the Aureliafile from the readme and ran aurelia bundle. This was the output:

> aurelia bundle

Would you like jspm to prefix the jspm package.json properties under jspm?:Yes
Enter server baseURL (public folder path):./
Enter jspm packages folder:.\jspm_packages
Enter config file path:.\config.js
Configuration file config.js doesn't exist, create it?:Yes
Enter client baseURL (public folder URL):/
Which ES6 transpiler would you like to use, Traceur or Babel?:traceur
Potentially unhandled rejection [6] Error: Error loading "aurelia-bootstrapper" at file:C:/Users/MyName/Source/MyName.MyProject/aurelia-bootstrapper.js
ENOENT, open 'C:\Users\MyName\Source\MyName.MyProject\aurelia-bootstrapper.js'
    at Error (native)

Currently by relying on a JavaScript file as the configuration for the CLI it prevents the ability to 'extend' the functionality of the CLI or make it able to work when upgrading versions. If the CLI is not upgraded it will throw errors for methods not being implemented.

I think the Aureliafile.js should be converted into a file that is of JSON format so that it is more extensible.

All functionality of the cli should be in a separate library. The cli should just automate this library. This would allow the library to be used directly inside of gulp or any other node-based tool.

Perhaps aurelia-tools is the best repo to move the core functionality into?

process.AURELIA is created when the cli is executed from the command line. If requiring the cli from local installation, it will be undefined.

We need to make sure process.AURELIA works for both API and CLI

Create tests for the exec-command

We are going to have to simulate the environment. I am looking into ways to do this.

Let's consider creating a project generator.

What is a Project?

If you would like an example, you can consider an old cli tool I made called Ari

However, This will be much simpler, yet more robust.

A project will be your typical skeleton navigation.
When creating a project directory we should also create a plugins directory outside of the project.

This plugins directory will contain generated plugins that have their own repositories.

Similar to SOA (Service Oriented Architecture) However, Aurelia-CLI should automate all build and watch tasks for each plugin included in the project.

This is very beneficial, especially if you want to be able to modify your plugins, yet see the changes immediately within you project.

What should we Automate?

After creating a project, and a plugin, We should allow a command named link

link will make a local jspm link form the plugin, and a local jspm install --linked from the project directory.

I will list other functionality once I have it properly described.

We now have a new dir we are adding to the cwd called .aurelia

any installed plugins will be installed in this directory.

After a release people need to manually jspm install each aurelia dependency, then jspm clean to tidy things up. Should a cli command be added to automate this?

The main module file "index.js" is currently exporting the constructor.

This can become an issue when the user wants to require aurelia-cli in multiple places.

This also requires the logic in the bin/aurelia.js to be changed as well, because we are creating a new instance and then passing it to the configFile.

Solution

If we would like access to the constructor, we can place the constructor on the prototype, and export a new instance.

Create a feature/lib that provides a nice API for spawning commands to child_process, and promises the output.

This will allow us to spin up child processes and run commands as if the user was running them.
The resolve will return the output that would originally be printed to the terminal.

We can parse this output and use it to our advantage, by generating code relevant to their environment.

Our code currently seems to follow different code-styles. It'd be nice if we could setup the file editorconfig as we need it and rely on those formats. Currently it says e.g. intends of 2 yet most of the files have 4 spaces.

In development we are using ES6. However, when I try to require the configFile, it is requiring(aurelia-cli);

This causes it to enforce a local require.

Once the file tries requiring I get this message:

(function (exports, require, module, __filename, __dirname) { import {Program}
                                                              ^^^^^^
SyntaxError: Unexpected token import
    at Module._compile (module.js:439:25)
    at Module._extensions..js (module.js:474:10)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/joelcox1/Jobs/Aurelia/cli/aurelia-cli/node_modules/babel/node_modules/babel-core/lib/babel/api/register/node.js:161:7)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/joelcox1/Jobs/Aurelia/cli/cli-test-2/node_modules/aurelia-cli/index.js:7:11)
    at Module._compile (module.js:456:26)
    at Module._extensions..js (module.js:474:10)

@ahmedshuhel Any thoughts?

Create tests for the executable command new.

We now have a config store that will generate the Aureliafile.

However, We are only generating a .js file.

The config store can only read/write/create a .js file.

For a list of extensions console.log(process.AURELIA.extensions)

The CLI exits if no local install is found. This prevents some one from creating a new project to begin with.

Simple Fix. In the executable file, remove the process.exit() when checking for the config file.

However, We should only provide specific commands if the config file is not found, like Help or New, or Init.

Create a service for modifying the package.json

the config store is reading the wrong aurelia file.

This issue was caused by the refactor(cli)

Simply point to the cwd('Aureliafile')

Usage:

$ aurelia plugin -r i18next

Should uninstall the i18next plugin.

I am working on a simpler, yet more efficient version of commanderJS, which needs to replace the current CommanderJS.

No worries about existing code, the API will remain the same.

Let's focus on getting a testing environment set up. CLI tools can be easy to make, and testing can become a difficult task. However, from experience, If we do not properly test based on machine or OS type, we can potentially run into some major refactoring problems!

The interface is already defined in the help command, but for reference again -

aurelia plugin [p] [-list, -l]                     List all installed plugins
  plugin [-h]                                      Show help for plugins
  plugin -a --add {plugin-name}                         Add plugin from Aurelia plugin repo
  plugin -r --remove {plugin-name}                      Disable plugin from project
  plugin -c --clear {plugin-name}               Completely remove plugin and files

This compliments the corresponding issue in the registry

There is a PR in the queue that contains a commands directory.

Once this PR is merged, we should move existing commands to this directory.

When moving each command, try following the same structure in place for the init command.

Create a command that allows developers to install custom commands.

Create tests for init, and init --env

Provide means to automatically parse Views for translatable messages and generates translation files.

https://github.com/i18next/i18next-parser

The rest of Aurelia itself is written with ES6/7. Consider setting up a process that would allow the cli to use ES6. This would likely involve configuring babel to compile and generate modules in CommonJS format. I haven't used Babel in this context yet, but I think it would be worth investigating for consistency sake.

Create a series of prompts that allow the developer to choose his build tool, based on the technologies he is using.

Create service to figure out what tools the developer may need may need.

This is a suggestion to be able to define multiple bundles easily and have the cli create multiple bundles based on that definition:

"bundles" {
   "aurelia": {
        "aurelia-animator-css": "github:aurelia/[email protected]",
        "aurelia-bootstrapper": "github:aurelia/[email protected]",
        "aurelia-dependency-injection": "github:aurelia/[email protected]",
        "aurelia-framework": "github:aurelia/[email protected]",
        "aurelia-http-client": "github:aurelia/[email protected]",
        "aurelia-router": "github:aurelia/[email protected]"
    },
    "vendor": {
        "bootstrap": "github:twbs/[email protected]",
        "prism": "github:PrismJS/prism@master",
        "showdown": "github:showdownjs/[email protected]"
    },
    "app" : {
        "src" : "src/*",
        "value-converters" : "lib/value-converters/*",
        "widgets" : "lib/widgets/*"
    }
}

This definition could be saved in the package.json or in the Aureliafile.js for example.

That would generate 3 bundles when using aurelia-cli bundle , without the need for any extra parameters.
One bundle containing all Aurelia components , one containing all vendor code, and one containing the code for the actual application.

This is just a thought, but i do think the need for users to define multiple bundles will get bigger as their applications get bigger.

Defining separate bundles can also allow the aurelia code and vendor code to be used as a bundled file during development because it is unlikely that the user will change any code in those bundles.
only the application code can be left unbundled during development.

for production having separate bundles also means that the loading can be optimized as some bundles can be loaded after the initial start of the app.