App

If app runs in applet mode, this will be the current applet's name. Otherwise, it will be undefined. See applet for details.

Applets container. Usefull to get all available applets in your app. See applet for details.

Parsed program arguments.

Example:

$ node index.js arg1 arg2
...
console.log(this.args) // it should print: ['arg1', 'arg2']

Parsed program options:

• Dash (-) breaks the string into object keys
• While colon (:) is used as namespace - object separator. If no such namespace found, it is saved under _.

Parsed object values are normalized to its primitives using dotenv-parse-variables

$ node index.js --my-name-first=John --my-name-last=Doe --my-birthDay=secret --nameSpace:path-subPath=true
...
// {
//   _: {
//    my: {
//       name: { first: 'John', last: 'Doe' },
//       birthDay: 'secret'
//     }
//   },
//   nameSpace: { path: { subPath: true } }
// }

All plugin's base classes are saved here for reference so that you can extend them in your own plugins.

Two basic classes from Bajo package are also provided: Base and Tools. These are the most used classes in Bajo plugin development. You can extend them to create your own plugin's base class:

// factory function to create your own plugin's base class
async function () {
  const { Base } = this.app.baseClass
  class MyBase extends Base {
    constructor(pkgName, app) {
      super(pkgName, app)
      this.myProperty = 'myValue' // your class property
    }

    async myMethod() {
      // your class method
    }
  }
}

Internal cache instance. This is used to store temporary data in memory for faster access.

Config handlers container. This is where all config handlers are stored. Each handler is responsible to read and write config file in a particular format. Bajo uses this heavily to read/write config files and/or anything that needs to be parsed/stringified from string to object and vice versa.

By default, there are three built-in handlers: .js, .json and .yml/.yaml. Use plugins to add more, e.g bajo-config lets you to use .toml.

Note: .js is for reading only, it cannot be used to write config file.

Parsed environment variables. Support dotenv (.env) file too!

• Underscore (_) between keys merge those keys into a single camel-cased key
• Double underscores (__) between keys breaks the key into nested objects
• Meanwhile a dot (.) between keys breaks the key into nested, name-spaced objects

Parsed object values are normalized to its primitives using dotenv-parse-variables

Example:

• MY_KEY=secret → { _: { myKey: 'secret' } }
• MY_KEY__SUB_KEY=supersecret → { _: { myKey: { subKey: 'supersecret' } } }
• MY_NS.MY_NAME=John → { myNs: { myName: 'John' } }

Tips: During boot process, Bajo will add APPDIR environment variable which points to your app's root directory.

Supported environments. Read-only

Gives you direct access to the most commonly used 3rd party library in a Bajo based app. No manual import necessary, always available, anywhere, anytime!

Instance of the system log. This will automatically be instantiated early during boot process. See Log for details.

App's main plugin namespace (main). Read-only

Copy of the provided options. See App.TOptions for details.

Original plugin's package names (not to be confused with plugin namespaces) container. Ypu can use this information to get the real package name of a plugin.

Reminder: In Bajo, plugin name/namespace is the camel-cased version of its package name. E.g. my-plugin → myPlugin.

Date/time when your app start. You can use this e.g. to calculate how long your app has been running. Read-only

Add and save plugin and its base class definition (if provided) to the app instance. You can then reference the plugin using its namespace, e.g. this.myPlugin or this['myPlugin'].

Dumping variable on screen. Like console.log with configurable options. Useful for quick debugging and testing. You can also use it to dump variables in production without worrying about performance because it is using Bajo's built-in cache to store the result of util's inspect, so it will only be processed once for each unique variable.

Any argument passed to this method will be displayed on screen. If the last argument is a string \q or .q, app will quit rightaway after dumping.

If you have bajoCli plugin installed, variables will be displayed in a nice box using boxen package. Otherwise, it will fallback to console.log with util's inspect result.

To have more control on how the variable is displayed, you can set options in Bajo's config under dump key. See Bajo.TConfig for details.

Terminate the app forcefully and back to console.

Get all loaded plugin namespaces.

Get all loaded plugins. Alias to getPlugins() with no namespace provided.

Method to list all supported config formats, that is, all file extensions that are supported by the app's config handlers.

Get plugin by its namespace or alias. If the plugin is not loaded, it will throw an error unless silent is set to true.

Get plugin data directory. If the directory does not exist, it will be created automatically unless ensureDir is set to false.

Resolve file path from:

• local/absolute file
• Bajo.TNsPathPairs e.g. myPlugin:/path/to/file.txt
• file under node_modules, e.g. myPlugin:node_modules/some-package/file.txt

Get loaded plugins by their namespaces. If no namespace is provided, it will return all loaded plugins.

Load internationalization & languages files for particular plugin by its namespace. It will load all supported languages defined in config.intl.supported and save them in this[ns].intl object.

Run application and begin the boot process. This method is called automatically by boot script.

Boot process includes:

• parsing environment values, program arguments, and options
• create Bajo instance & initialize it
• load all plugins, their hooks, their configs and any other necessary services & resources
• run in applet mode if -a or --applet is given

After boot process is completed, hook bajo:afterBoot is triggered.

If app mode is applet, it runs your choosen applet instead.

Start a plugin by its namespace. It will call the plugin's start method with the provided arguments.

Stop a plugin by its namespace. It will call the plugin's stop method with the provided arguments.

Reserved for future use.

Note: Basically it is not a good idea to stop a plugin because other plugins might be dependent on it. But if we could find a way to safely stop a plugin without breaking things, this will be a cool feature because it allows dynamic management of plugins without restarting the application.

Translate text to the current language.

It will search for the translation in the plugin's intl object first, interpolating the parameters if found, then fallback to bajo plugin's intl object if not found.

If the last parameter is an object with lang key, it will use that language instead of the default one.

There is a shortcut to this method attached on all plugins. You'll normally call that shorcut instead of this method, because that shortcut is bound to plugin's namespace already

... within your main plugin
const translated = this.app.t('main', 'My cute cat is %s', 'purring')
// or within your plugin
const translated = this.t('My cute cat is %s', 'purring')

Check whether translation text/key exists.

Config handler definition. Your own handler must follow this structure.

Supported environments.

Environment is one of the most important aspect of a Bajo app. It is used to determine how your app should behave in different environments. It allows you to have different configurations and settings, and as a plugin developer, you can also use it to determine how your plugin should behave in different environments.

Most commonly used libraries by Bajo and its plugins. They are already imported and ready to use, so you don't have to import them again in your plugin.

Example:

const { fs, dayjs } = this.app.lib
fs.ensureDirSync('/path/to/dir')
const now = dayjs().format('YYYY-MM-DD HH:mm:ss')

Options object passed to App constructor. By default, you don't need to pass any options, unless you want to manually override the default behavior.

Your read handler must follow this structure. It is used to read and parse config file in a particular format.

Your write handler must follow this structure. It is used to write config file in a particular format.