Main entry point of a Bajo app. Returned value is the App instance itself.

Inside your index.js file in the root folder, write something like this:

import { boot } from 'bajo'
const app = await boot()
// At this point, your app should be ready to use
// You can now use `app` to access all plugins and their features

Even though you can write your codes directly after boot as shown above, we strongly suggest writing your code inside the Main plugin or even writing a custom Plugin.

We recommend the second method for its portability.

This is the default configuration object for Bajo and its plugins (see note below). It contains various settings that control the behavior of the framework. You can override these settings by providing your own configuration object through the following methods in the order of priority:

1. Environment variables: You can set configuration options using environment variables too. dotenv is also supported. The environment variable names should be in uppercase. Use double underscores instead of dots and single underscores to form camel cased name. For example, LOG__TIME_TAKEN=true will set log.timeTaken to true

2. Command-line arguments: You can pass configuration options as command-line arguments when starting the application. For example, you can use --env=prod to set the environment to prod. For nested configuration options, use dash notation. For example, --log-timeTaken will set log.timeTaken to true.

3. Configuration files: Create/open {dataDir}/config/bajo.{ext} file, where {ext} is the file extension of your choice. This file is read during the boot process with app's App#configHandlers and merged with the default configuration object.

   By default, the supported file extensions are .js, .json, and .yml/.yaml. More extensions can be added by plugins. For example, the bajo-config plugin provides support for .toml format.

   If the same filename with different extension exists, the one with higher priority will be used. The priorities are as follows:

   1. .js - use this if you want to use dynamic config file that can be generated programmatically.
   2. .json - use this if you want to use static config file that can be easily edited by humans.
   3. .yml/.yaml - use this if you want to use static config file that can be easily edited by humans and supports comments.

   To have an environment-specific configuration, create a file named bajo-{env}.{ext} where {env} is the environment name (e.g. dev, prod) in the same folder.

Note: all plugin's configuration files follow the same rules as above, but with the following differences:

• The configuration file should be named as {pluginName}.{ext} or {pluginName}-{env}.{ext} for environment-specific configuration, where {pluginName} is the name of the plugin.
• Command-line arguments should be prefixed with the plugin name followed by a colon. For example, --{pluginName}:my-configKey will set my.configKey to the value provided for the plugin's configuration.
• Environment variables should be prefixed with the plugin name followed by a dot. For example, {PLUGINNAME}.MY__CONFIG_KEY will set my.configKey to the value provided for the plugin's configuration.

Plugin's configuration objects are mutable only during the boot process. After a plugin is started, they are frozen and cannot be modified. Your only options to do modifications is to use {pluginName}:{before|after}{Init|Start} hooks.

To be recognized as a valid Bajo app, your package must be an ES6 module and have a package.json file with the additional bajo property and at least the type property set to app.

You can also add the plugins property to specify which plugins to load. But this will be overridden by the {dataDir}/config/.plugins file if it exists.

Example:

{
  "name": "my-app",
  "version": "1.0.0",
  "description": "My Bajo app",
  "type": "module",
  "main": "index.js",
  "bajo": {
    "type": "app",
    "plugins": ["bajo-cli", "bajo-config"]
  },
  "dependencies": {
    "bajo": "^2.23.0",
    "bajo-cli": "^2.4.0",
    "bajo-config": "^2.4.0"
  }
}
...

Note: The dot symbol in package.json has been replaced with · symbol because of JSDoc theme limitation