Remus

The Remus Application Framework is a typescript based framework for the realization of complex applications. It consists of various components. Some of them can be used independently from each other.

Components

The Logger

Provides a convenient source code interface for logging tasks. Log messages are created using a method chaining approach and may use various properties such as the log level, ids, source references, origin (environment) references, etc. Different appenders are available, e.g. a ColourConsoleAppender and a FileAppender. It is possible to configure the Loggers in a way that log messages can be filtered by their properties and piped to designated appenders and in a way that logger instances can be configured to propagate various properties into their log messages so that they either act as default properties that, thus, do not need to be specified on each log call, or the final property values are determined by the logger instance and the concrete values provided to the log call.

The Command Line Interface

Provides a complex feature for the modeling of an application's command line interface. In contrast to other existing node command line parsers, it provides the following additional features:

1. A scriptable internal API for modeling the CLI: Most libraries out there consume one object containing the CLI description without the chance to alter the model afterwards which may be necessary due to asynchronous things going on on application start.

2. A multi-paradime approach: Depending on the needs, a command is a simple executable entity that may or may not provide options or sub-commands. However, a command could also be seen as the combination of a verb (do something) and an entity (with what). When using verbs, a slightly different approach for their registration is to be used: verbs shall be globally defined and yet dis- and enableable for each individual entity or entity type whilst having a different meaning on each entity.

3. A comprehensive and detailed execution flow: Calls to an application may use an arbitrarily complex structure of commands, subcommands, verbs, and options. In order to have things ready for a subcommand, a superordinate command may need to do things within the environment prior to the execution of the subcommand, depending on its options. In turn, processing options in the context of a command may be done prior to this. For that, the execution model provides different lifecycle hooks that are executed in the sequence that is given by the concrete command line arguments and the configured CLI model.

4. An extension API that enables the efficient reuse of commands and their options: Software is not monolithic, it is devided into modules and plugins the structure of which may not be determined at development time. Plugins can hook into existing commands, add, alter, or hide options, or extend and replace existing commands. For that, an internal command registry is used that allow such extension, e.g. using JavaScript decorators.

5. An included, and thus, standardized, yet customizable help text generator.