Merge pull request #80 from AthennaIO/develop

Improve docs

docs/architecture-concepts/application-lifecycle.mdx

@@ -35,10 +35,9 @@ application you are using. Meaning that no matter what is the type of
 application you are using to build your solution, the explanation bellow
 is valid for all of them.
 
-The entry point of an Athenna application is the `bootstrap/main.ts`
-file in the default project structure and `bin/main.ts` in slim project
-structure. The first action taken by Athenna itself is to create an
-instance of the application and then boot it.
+The entry point of an Athenna application is the `Path.bootstrap('main.ts')`. 
+The first action taken by Athenna itself is to create an instance of the 
+application and then boot it.
 
 ## Loading the foundation
 
@@ -119,10 +118,11 @@ in the `.athennarc.json` in the `preloads` array.
 :::note
 
 The process of firing the Athenna foundation is triggered by the
-`Ignite.fire` method. But if you check your `main.ts` entrypoint file,
-you will see that this method is not called directly. The reason for
-this is that this method is called internally depending on the type of
-application you are using. Let's cover some examples bellow:
+`Ignite::fire()` static method. But if you check your `Path.bootstrap('main.ts')` 
+entrypoint file, you will see that this method is not called directly. 
+The reason for this is that this method is called internally depending 
+on the type of application you are using. Let's cover some examples 
+bellow:
 
 - The `REST API` application needs to fire the foundation first because
 it depends on service providers to register your controllers, services,
@@ -141,7 +141,7 @@ will be fired before executing your command.
 ### Kernel
 
 The Kernel class is responsible by defining some bootstraps that will
-be run before reading your `routes/http.ts` file. These bootstraps
+be run before reading your `Path.routes('http.ts')` file. These bootstraps
 configure error handling for requests, tracing and logging, detect the
 application environment, and perform other tasks that need to be done
 before the request is actually handled. Typically, these classes handle
@@ -169,27 +169,27 @@ implementation code.
 
 :::
 
-Then, you can register your `CustomKernel` in your `bootstrap/main.ts`
+Then, you can register your `CustomKernel` in your `Path.bootstrap('main.ts')`
 file:
 
 ```typescript
 import { Ignite } from '@athenna/core'
 
 const ignite = await new Ignite().load(import.meta.url)
 
-await ignite.httpServer({ kernelPath: '#app/http/CustomKernel' })'
+await ignite.httpServer({ kernelPath: '#app/http/CustomKernel' })
 ```
 
 ### Routes
 
-The `routes/http.ts` file is the entrypoint for all your http requests.
+The `Path.routes('http.ts')` file is the entrypoint for all your http requests.
 This file is responsible to create a contract between your client and
 your application. It Is in here that we define all our routes and the
 handlers/controllers who will handle the client request.
 
 One of the most important service providers in your application is the
 `HttpRouteProvider`. This service provider adds in the container the
-`Route` class instance used inside `routes/http.ts` file.
+`Route` class instance used inside `Path.routes('http.ts')` file.
 
 When the client request arrives, the server first executes all your
 global middlewares, then it will execute all your route middlewares.
@@ -276,8 +276,8 @@ kernel implementation taking a look at [ConsoleKernel](https://github.com/Athenn
 
 :::
 
-Then, you can register your `CustomKernel` in your `bootstrap/main.ts` or
-`bootstrap/artisan.ts` file:
+Then, you can register your `CustomKernel` in your 
+`Path.bootstrap('main.ts')` or `Path.bootstrap('artisan.ts')` file:
 
 ```typescript
 import { Ignite } from '@athenna/core'
@@ -291,9 +291,9 @@ await ignite.artisan({ kernelPath: '#app/http/CustomKernel' })
 
 ### Execution
 
-The `routes/console.ts` and the `commands` property of `.athennarc.json` file
-is where that we define all ours commands and the handlers who will handle
-the terminal arguments.
+The `Path.routes('console.ts')` and the `commands` property of 
+`.athennarc.json` file is where that we define all ours commands 
+and the handlers who will handle the terminal arguments.
 
 When the terminal arguments arrive, the application will be bootstrapped
 based on the command that you are asking to execute. Let's suppose we have
@@ -319,10 +319,10 @@ command and execute it:
 ```mermaid
 flowchart LR
     terminalCommand(("Terminal Command"))
-    igniteLoad{"Ignite.load()"}
+    igniteLoad{"Ignite::load()"}
     consoleKernel{"ConsoleKernel"}
     loadAppEqualsTrue{"loadApp === true"}
-    igniteFire{"Ignite.fire()"}
+    igniteFire{"Ignite::fire()"}
     defineArgsAndFlags{"Define arguments and flags"}
     commandHandler("Command Handler")
 

docs/architecture-concepts/service-container.mdx

@@ -56,7 +56,7 @@ itself.
 If you use the `@Service` annotation, you can instruct the container how he
 should resolve that class, or use the default resolution configurations of the
 annotation. For example, you may place the following code in your
-`routes/http.ts` file:
+`Path.routes('http.ts')` file:
 
 ```typescript
 import { Route } from '@athenna/http'

docs/architecture-concepts/service-providers.mdx

@@ -173,7 +173,7 @@ The following environments are available by default in Athenna at this moment:
 - repl
 - console
 
-You could also create your own environments. In your `bootstrap/main.ts` file
+You could also create your own environments. In your `Path.bootstrap('main.ts')` file
 you can add an `environments` option when calling `Ignite.load` method:
 
 ```typescript

docs/cli-application/error-handling.mdx

@@ -27,7 +27,7 @@ This documentation will cover about error handling in the **CLI**
 application, which means that only errors that happens inside 
 the `handle()` method of commands and bellow that will be handled:
 
-```typescript title="app/console/commands/AppCommand.ts"
+```typescript title="app/console/commands/AppCommand.js"
 import { BaseCommand } from '@athenna/artisan'
 import { AppService } from '#app/services/AppService'
 
@@ -62,7 +62,7 @@ bootstrap failure has been found in your application.
 
 ## Configuration
 
-The `debug` option in your `config/app.ts` configuration
+The `debug` option in your `Path.config('app.ts')` configuration
 file determines how much information about an error is
 actually displayed to the user. By default, this option is
 set to respect the value of the `APP_DEBUG` environment
@@ -77,13 +77,13 @@ users.
 
 Every error will be logged by default using the `console`
 driver from `@athenna/logger`. By default, Athenna uses the
-`exception` channel of your `config/logging.ts` file to log
+`exception` channel of your `Path.config('logging.ts')` file to log
 all exceptions that happens in your application.
 
 :::tip
 
 You can change the driver and formatter of `exception`
-channel inside `config/logging.ts` file. This way you can
+channel inside `Path.config('logging.ts')` file. This way you can
 send all your error logs to another provider and with
 a different formatter.
 
@@ -115,13 +115,38 @@ always be considered as a not treated exception.
 
 :::
 
+## Simple exceptions
+
+When talking about exceptions in Artisan and CLI applications,
+we can divide them into two categories: simple exceptions and
+the more complex ones. Simple exceptions are exceptions that
+when handled by the `ConsoleExceptionHandler` will only log the
+exception **message**. The more complex will log the entire exception
+including **code, message, help and stack trace**.
+
+Simple exceptions are recognized by `ConsoleExceptionHandler` by
+the `code`. If the code is `E_SIMPLE_CLI`, it will be considered
+as a simple exception:
+
+```typescript title="app/console/exceptions/NotFoundDatabaseException.js"
+import { Exception } from '@athenna/common'
+
+export class NotFoundDatabaseException extends Exception {
+  public constructor(databaseName: string) {
+    const code = 'E_SIMPLE_CLI' 👈
+
+    super({ code, message: `Database ${databaseName} not found.` })
+  }
+}
+```
+
 ## Implementing your own exception handler
 
 Let's suppose you want to write a custom logic for handling
 your exceptions. You can do so by creating your own
 exception handler:
 
-```typescript title="app/console/exceptions/Handler.ts"
+```typescript title="app/console/exceptions/Handler.js"
 import { ConsoleExceptionHandler } from '@athenna/artisan'
 
 export class Handler extends ConsoleExceptionHandler {
@@ -134,7 +159,7 @@ export class Handler extends ConsoleExceptionHandler {
 Now you need to register your exception handler when 
 bootstrapping your application:
 
-```typescript title="bootstrap/main.ts"
+```typescript title="Path.bootstrap('main.ts')"
 await ignite.artisan(process.argv, { 
   displayName: 'Athenna',
   exceptionHandlerPath: '#app/console/exceptions/Handler', 👈

docs/cli-application/running.mdx

@@ -58,3 +58,41 @@ And now the `yourCliCommand` will exist in your actual Node.js version:
 ```shell
 yourCliCommand --help
 ```
+
+## Display CLI name
+
+When running your CLI without any option and command, the display
+name will be rendered in the terminal using 
+[`chalk-rainbow`](https://www.npmjs.com/package/chalk-rainbow) 
+and [`figlet`](https://www.npmjs.com/package/figlet).
+
+By default Artisan always display the `Artisan` name, but you can
+change it for your own display name by setting the `displayName` 
+property in `Ignite.artisan()` method:
+
+```typescript title="Path.bootstrap('main.ts')"
+import { Ignite } from '@athenna/core'
+
+const ignite = await new Ignite().load(import.meta.url)
+
+await ignite.artisan({
+  displayName: 'Your CLI Command', 👈
+})
+```
+
+:::tip
+
+If you wish to disable the display name, just set the `displayName`
+as `null`:
+
+```typescript title="Path.bootstrap('main.ts')"
+import { Ignite } from '@athenna/core'
+
+const ignite = await new Ignite().load(import.meta.url)
+
+await ignite.artisan({
+  displayName: null, 👈
+})
+```
+
+:::

docs/digging-deeper/graceful-shutdown.mdx

@@ -105,9 +105,9 @@ Node.js supports registering as many as signals event
 listeners you want, this means that you can use the default
 `SIGINT` and `SIGTERM` listeners of Athenna and also create 
 your own. We recommend doing this implementation in the bootstrap
-file of your like application, like `bootstrap/main.ts`:
+file of your like application:
 
-```typescript
+```typescript title="Path.bootstrap('main.ts')"
 import { Ignite } from '@athenna/core'
 
 const ignite = await new Ignite().load(import.meta.url)
@@ -125,7 +125,7 @@ process.on('SIGTERM', () => {
 
 If you wish to remove or change the default listeners of
 Athenna, or also listen to new signals, you can create 
-the `signals` property in the `config/app.ts`
+the `signals` property in the `Path.config('app.ts')`
 file:
 
 ```typescript

docs/digging-deeper/repl.mdx

@@ -50,7 +50,7 @@ To import modules inside REPL you need to use dynamic imports:
 
 ```javascript
 { Log } = await import('@athenna/logger') // Destructuring import
-helpers = await import('#src/Helpers/index') // Default import
+helpers = await import('#app/helpers/index') // Default import
 ```
 
 :::caution

docs/getting-started/athennarc-file.mdx

@@ -42,14 +42,61 @@ also register it inside your `.athennarc.json` file:
 }
 ```
 
+## Custom RC file path
+
+You can change the name and the path of your RC file or even 
+create customized ones for each environement (`.athennarc.dev.json`, 
+`.athennarc.prod.json`). To do that you need to set the new 
+path to `Ignite::load()` static method:
+
+```typescript title="Path.bootstrap('dev.ts')"
+import { Ignite } from '@athenna/core'
+
+const ignite = await new Ignite().load(import.meta.url, {
+  athennaRcPath: './bootstrap/athennadevrc.json' 👈
+})
+
+await ignite.httpServer()
+```
+
+:::tip
+
+Always remember that when using relative paths to set something
+in Athenna, you need to use your project root path as reference,
+just like in the example above.
+
+:::
+
+## Using RC file in `package.json`
+
+You can also use the RC file inside `package.json`. By default,
+If you don't specify the path of your RC file, and the default 
+`.athennarc.json` cannot be found in the root path of your application,
+Athenna will check if the `athenna` property exists in your `package.json`:
+
+```json title="package.json"
+{
+  "athenna": {
+    "providers": [
+      "@athenna/core/providers/CoreProvider",
+      "@athenna/http/providers/HttpRouteProvider",
+      "@athenna/http/providers/HttpServerProvider"
+    ],
+    "directories": {
+      "bootstrap": "bin"
+    }
+  }
+}
+```
+
 ## The `preloads` property
 
 An array of files that will be loaded when your application
 is bootstrapping. The files are loaded after booting the
 service providers. You can do anything you want in preload
 files. Check the example bellow:
 
-```typescript filename="say-hello.js"
+```typescript title="say-hello.js"
 import { Log } from '@athenna/logger'
 import { Config } from '@athenna/core'