@terminal-packages/cli

Hex CLI

Build on top of terminal, from the command line

Installation

$ npm install -g @terminal-packages/cli

Build

$ npm run build

Watch Build

$ npm run watch

Lint

$ npm run lint

Usage

Just type hex on the command line and the CLI usage will appear:

Usage: hex [options] [command]

Options:
  -V, --version  output the version number
  -h, --help     output usage information

Commands:
  config         Show configuration
  contracts      Contract CLI commands
  projects       Projects CLI commands
  ganache        Create, delete and get info for ganache instances
  login          Login to your terminal account
  logs           Get logs for your terminal account
  logout         Logout of the CLI
  teams          Teams information
  help [cmd]     Display help for [cmd]

$ hex ganache create --yaml=./ganache.yaml

example YAML format:

team

team: 'my-team'
project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'

team forked

team: 'my-team'
project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'
      forkNetwork: 'main'
      forkBlockNumber: 587

team: 'my-team'
project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'
      forkNetwork: 'main'

user

project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'

user forked

project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'
      forkNetwork: 'main'
      forkBlockNumber: 587

project: 'my-project'
resources:
  ganaches:
    - name: 'my-ganache'
      folder: 'ganache'
      forkNetwork: 'main'

Development app structure

cli structure

COMMANDS > CONTROLLERS > SERVICES

cli > commands

This is where you create any public CLI interfaces, this will pick up the command line execution, validate the arguments and pass it to the controller if successful. It will also be in control of rendering any validation errors back to the console for the user. The commands should only ever speak to the controllers and never any services.

cli > controllers

This is where the command controllers live. This is in control of all the logic of what the command needs to go and do, it can inject any of the services into itself. A command object say for example config should always have its own controller. Controllers are always named with .controller.ts at the end. Controllers should always be @injectable() so we can make use of our DI in this app.

cli > services

This is where reusable services live. These should always be @injectable() and never inject a controller within them, it can inject other services but be careful of circular dependencies. Services are always named with .service.ts at the end. Anything which is more generic and could be shared across more then 1 controller should be a service unless its a simple utils method.

Dependency injection

We use DI heavily in this cli to allow us to reuse and create lovely reuseable neat code. If you do create a new service or controller and want to make it injectable firstly you have to add @injectable() above it:

@injectable()
export class ExampleService {
...

then you will need to register it in the dependency-injection/container.ts:

DIContainer.bind<ExampleService>(ExampleService).toSelf();

You can also register it as a singleton scope:

DIContainer.bind<ExampleService>(ExampleService)
  .toSelf()
  .inSingletonScope();

There is also a lot of other scopes you can add:

  inSingletonScope(): BindingWhenOnSyntax<T>;
  inTransientScope(): BindingWhenOnSyntax<T>;
  inRequestScope(): BindingWhenOnSyntax<T>;
  when(constraint: (request: Request) => boolean): BindingOnSyntax<T>;
  whenTargetNamed(name: string | number | symbol): BindingOnSyntax<T>;
  whenTargetIsDefault(): BindingOnSyntax<T>;
  whenTargetTagged(tag: string | number | symbol, value: any): BindingOnSyntax<T>;
  whenInjectedInto(parent: (Function | string)): BindingOnSyntax<T>;
  whenParentNamed(name: string | number | symbol): BindingOnSyntax<T>;
  whenParentTagged(tag: string | number | symbol, value: any): BindingOnSyntax<T>;
  whenAnyAncestorIs(ancestor: (Function | string)): BindingOnSyntax<T>;
  whenNoAncestorIs(ancestor: (Function | string)): BindingOnSyntax<T>;
  whenAnyAncestorNamed(name: string | number | symbol): BindingOnSyntax<T>;
  whenAnyAncestorTagged(tag: string | number | symbol, value: any): BindingOnSyntax<T>;
  whenNoAncestorNamed(name: string | number | symbol): BindingOnSyntax<T>;
  whenNoAncestorTagged(tag: string | number | symbol, value: any): BindingOnSyntax<T>;
  whenAnyAncestorMatches(constraint: (request: Request) => boolean): BindingOnSyntax<T>;
  whenNoAncestorMatches(constraint: (request: Request) => boolean): BindingOnSyntax<T>;

To inject other services/controllers into your new class:

@injectable()
export class ExampleService {
  constructor(
    @inject(ExampleService2)
    private _exampleService2: ExampleService2
  ) {}
}

If you want to get a injectable class when you're not in a class you can use:

import DIContainer from './dependency-injection/container';
import { TestController } from './controllers/test/test.controller';

const controller = DIContainer.resolve<TestController>(TestController);
// whoop controller has a instance of `TestController` and can start calling
// the methods

Testing with DI

The container makes this super easy to switch out mocked injectable services into your controller/service.

describe("ExampleService", () => {
    // unbind the authentication normal injectable service
    DIContainer.unbind(AuthenticationService);

    // bind your mocked service to your authentication service
    DIContainer.bind(AuthenticationService).to(MockAuthenticationService);

    // this has a `AuthenticationService` injectable parameter and it will be
    // autoresolved to `MockAuthenticationService` due to the above
    const exampleService: ExampleService = DIContainer.get(ExampleService);

    ... // start writing your tests