docs: move documentation into monorepo

Migrate the existing lb4 files under the docs folder of the monorepo

docs/Application-generator.md

@@ -0,0 +1,99 @@
+---
+lang: en
+title: 'Application generator'
+keywords: LoopBack 4.0, LoopBack 4
+tags:
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/Application-generator.html
+summary:
+---
+
+### Synopsis
+
+Creates a new LoopBack4 application using REST API.
+
+```
+lb4 [app] [options] [<name>]
+```
+
+### Options
+
+`--applicationName`
+: Application name.
+
+`--description`
+: Description of the application.
+
+`--outDir`
+: Project root directory for the application.
+
+`--tslint`
+: Add TSLint to LoopBack4 application project.
+
+`--prettier`
+: Add Prettier to LoopBack4 application project.
+
+`--mocha`
+: Add Mocha to LoopBack4 application project.
+
+`--loopbackBuild`
+: Add @loopback/build module's script set to LoopBack4 application project.
+
+{% include_relative includes/CLI-std-options.md %}
+
+### Arguments
+
+`<name>` - Optional name of the application given as an argument to the command. 
+If provided, the tool will use that as the default when prompting for the name.
+
+### Interactive Prompts
+
+The tool will prompt you for:
+
+- Name of the application as will be shown in `package.json`.
+If the name had been supplied from the command-line, the prompt is skipped and the application is built with the name from the command-line argument.
+Must follow npm naming conventions.
+
+- Description of the application as will be shown in `package.json`.
+
+- Name of the directory in which to create your application.
+Defaults to the name of the application previously entered.
+
+- Name of the Application class in `application.ts`.
+Defaults to <code><i>name</i>Application</code>.
+
+- Optional modules to add to the application. These modules are helpful tools to help format, test, and build a LoopBack4 application.
+Defaults to `true` for all of the modules.
+The prompted modules are:
+
+  - [`tslint`](https://www.npmjs.com/package/tslint)
+  - [`prettier`](https://www.npmjs.com/package/prettier)
+  - [`mocha`](https://www.npmjs.com/package/mocha)
+  - [`@loopback/build`](https://www.npmjs.com/package/@loopback/build)
+
+### Output
+
+The core scaffold of a LoopBack4 application generated by the CLI consists of the following files and directories:
+
+```
+.
+├── src/
+|   ├── controllers/
+|   |   └── ping.controller.ts
+|   ├── datasources/
+|   ├── models/
+|   ├── repositories/
+|   ├── application.ts
+|   ├── index.ts
+|   └── sequence.ts
+├── test/
+└── package.json
+```
+
+`ping.controller.ts` is a file used to provide the application with a responsive endpoint.
+It contains logic to respond with a greeting message when the appliaction receives a `GET` request from endpoint `/ping`.
+
+`cd` to the application's newly created directory and run `npm start` to see the application running at `localhost:3000`.
+Go to `localhost:3000/ping` to be greeted with a message.
+
+Once the application has been created, additional generators such as [controller generator](Controller-generator.md) can be run from the application's root directory to further scaffold the application.

docs/Application.md

@@ -0,0 +1,217 @@
+---
+lang: en
+title: 'Application'
+keywords: LoopBack 4.0, LoopBack 4
+tags:
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/Application.html
+summary:
+---
+
+## What is an Application?
+
+In LoopBack 4, the [`Application`](http://apidocs.strongloop.com/@loopback%2fcore/#Application)
+class is the central class for setting up all of your module's components,
+controllers, servers and bindings. The `Application` class extends
+[Context](Context.md), and provides the controls for starting and stopping
+itself and its associated servers.
+
+When using LoopBack 4, we strongly encourage you to create your own subclass
+of `Application` to better organize your configuration and setup.
+
+## Making your own application class
+
+By making your own application class, you can perform several additional
+tasks as a part of your setup:
+- Pass configuration into the base class constructor
+- Perform some asynchronous wireup before application start
+- Perform some graceful cleanup on application stop
+
+{% include code-caption.html content="src/widget-application.ts" %}
+```ts
+import {Application} from '@loopback/core';
+import {RestComponent, RestServer} from '@loopback/rest';
+import {SamoflangeController, DoohickeyController} from './controllers';
+import {WidgetApi} from './apidef/';
+
+export class WidgetApplication extends Application {
+  constructor() {
+    // This is where you would pass configuration to the base constructor
+    // (as well as handle your own!)
+    super();
+    const app = this; // For clarity.
+    // You can bind to the Application-level context here.
+    // app.bind('foo').to(bar);
+    app.component(RestComponent);
+    app.controller(SamoflangeController);
+    app.controller(DoohickeyController);
+  }
+
+  async start() {
+    // This is where you would asynchronously retrieve servers, providers and
+    // other components to configure them before launch.
+    const server = await app.getServer(RestServer);
+    server.bind('rest.port').to(8080);
+    server.api(WidgetApi);
+    // The superclass start method will call start on all servers that are
+    // bound to the application.
+    return await super.start();
+  }
+
+  async stop() {
+    // This is where you would do whatever is necessary before stopping your
+    // app (graceful closing of connections, flushing buffers, etc)
+    console.log('Widget application is shutting down...')
+    // The superclass stop method will call stop on all servers that are
+    // bound to the application.
+    await super.stop();
+  }
+}
+
+```
+
+## Configuring your application
+Your application can be configured with constructor arguments, bindings, or
+a combination of both.
+
+### Binding configuration
+Binding is the most commonly-demonstrated form of application configuration
+throughout our examples, and is the recommended method for setting up your
+application.
+
+In addition to the binding functions provided by [Context](Context.md),
+the `Application` class also provides some sugar functions for commonly used
+bindings, like `component`, `server` and `controller`:
+
+```ts
+export class MyApplication extends Application {
+  constructor() {
+    super();
+    this.component(MagicSuite);
+    this.server(RestServer, 'public');
+    this.server(RestServer, 'private');
+
+    this.controller(FooController);
+    this.controller(BarController);
+    this.controller(BazController);
+  }
+}
+```
+
+You can find a complete list of these functions on the
+[`Application`](http://apidocs.loopback.io/@loopback%2fcore/#Application) API
+docs page.
+
+Additionally, you can use more advanced forms of binding to fine-tune your
+application's configuration:
+
+```ts
+export class MyApplication extends Application {
+  constructor() {
+    super();
+    this.server(RestServer);
+    this.controller(FooController);
+    this.bind('fooCorp.logger').toProvider(LogProvider);
+    this.bind('repositories.widget')
+      .toClass(WidgetRepository)
+      .inScope(BindingScope.SINGLETON);
+  }
+}
+```
+In the above example:
+- injection calls for `fooCorp.logger` will be handled by the `LogProvider`
+  class.
+- injection calls for `repositories.widget` will be handled by a singleton
+instance of the `WidgetRepository` class.
+
+#### Components
+```ts
+app.component(MyComponent);
+app.component(RestComponent);
+```
+The `component` function allows binding of component constructors within
+your `Application` instance's context.
+
+For more information on how to make use of components,
+see [Using Components](Using-components.md).
+
+#### Controllers
+```ts
+app.controller(FooController);
+app.controller(BarController);
+```
+Much like the component function, the `controller` function allows
+binding of [Controllers](Controllers.md) to the `Application` context.
+
+#### Servers
+```ts
+app.server(RestServer);
+app.servers([MyServer, GrpcServer]);
+```
+The `server` function is much like the previous functions, but
+with [Servers](server.md) bulk bindings are possible through the function
+`servers`.
+
+```ts
+const app = new Application();
+app.server(RestServer, 'public'); // {'public': RestServer}
+app.server(RestServer, 'private'); // {'private': RestServer}
+```
+In the above example, the two server instances would be bound to the Application
+context under the keys `servers.public`, and `servers.private` respectively.
+
+### Constructor configuration
+
+The `Application` class constructor also accepts an
+[`ApplicationConfig`](http://apidocs.strongloop.com/@loopback%2fcore/#ApplicationConfig)
+object which contains component-level configurations such as
+[`RestServerConfig`](http://apidocs.strongloop.com/@loopback%2frest/#RestServerConfig).
+It will automatically create bindings for these configurations and later be injected
+through dependency injections. Visit [Dependency Injection](Dependency-injection.md)
+for more details.
+
+{% include note.html content="
+  Binding configuration such as component binding, provider binding, or binding scopes
+  are not possible with the constructor-based configuration approach.
+" %}
+
+```ts
+export class MyApplication extends RestApplication {
+  constructor() {
+    super({
+      rest: {
+        port: 4000,
+        host: 'my-host'
+      }
+    })
+  }
+}
+```
+
+## Tips for application setup
+Here are some tips to help avoid common pitfalls and mistakes.
+
+### Use unique bindings
+Use binding names that are prefixed with a unique string that does not overlap
+with loopback's bindings. As an example, if your application is built for
+your employer FooCorp, you can prefix your bindings with `fooCorp`.
+```ts
+// This is unlikely to conflict with keys used by other component developers
+// or within loopback itself!
+app.bind('fooCorp.widgetServer.config').to(widgetServerConfig);
+```
+
+### Avoid use of `getSync`
+We provide the [`getSync`](http://apidocs.loopback.io/@loopback%2fcontext/#getSync)
+function for scenarios where you cannot asynchronously retrieve your bindings,
+such as in constructor bodies.
+
+However, the number of scenarios in which you must do this are limited, and you
+should avoid potential race conditions and retrieve your bindings asynchronously
+using the [`get`](http://apidocs.loopback.io/@loopback%2fcontext/#get) function
+whenever possible.
+
+### Use caution with singleton binding scopes
+By default, bindings for controllers will instantiate a new instance whenever
+they are injected or retrieved from their binding. Your application should only
+set singleton binding scopes on controllers when it makes sense to do so.

docs/Best-practices-with-Loopback-4.md

@@ -0,0 +1,19 @@
+---
+lang: en
+title: 'Best practices with Loopback 4'
+keywords: LoopBack 4.0, LoopBack 4
+tags:
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/Best-practices-with-Loopback-4.html
+summary:
+---
+
+LoopBack 4 is more than just a framework: It’s an ecosystem that encourages developers to follow best practices through predefined standards. This section will walk through some important guidelines by building an example API for a catalog of products.
+
+Our best practice follows an "API first" and test-driven development approach:
+
+1. [**Defining and validating the API**](./Defining-and-validating-the-API.md): This section guides you through constructing your API first before any internal logic is added.
+2. [**Testing the API**](./Testing-the-API.md): This section describes the process of writing smoke test for your API and its spec.
+3. [**Defining your testing strategy**](./Defining-your-testing-strategy.md): This section discusses the advantages and the process of building a strong testing suite.
+4. [**Implementing features**](./Implementing-features.md): This section demonstrates how the tests for each feature of your application should be written, and how to write the logic to make these tests pass. In the example, the tests for the controller, model, repository, data source, and sequence are written and then implemented.
+5. [**Preparing the API for consumption**](./Preparing-the-API-for-consumption.md): This section shows how the endpoints can be physically tested using the Swagger UI.

docs/Calling-other-APIs-and-Web-Services.md

@@ -0,0 +1,17 @@
+---
+lang: en
+title: 'Calling other APIs and web services'
+keywords: LoopBack 4.0, LoopBack 4
+tags:
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/Calling-other-APIs-and-web-services.html
+summary:
+---
+Your API implementation often needs to interact with REST APIs, SOAP Web Services or other forms of APIs.
+
+How to:
+- Set up a Service
+- Use services with controllers
+- Reuse models between services and controllers
+
+{% include content/tbd.html %}

docs/Command-line-interface.md

@@ -0,0 +1,27 @@
+---
+lang: en
+title: 'Command-line interface'
+keywords: LoopBack 4.0, LoopBack 4
+tags:
+sidebar: lb4_sidebar
+permalink: /doc/en/lb4/Command-line-interface.html
+summary:
+---
+
+LoopBack 4 provides command-line tools to help you get started quickly. The command line tools generate application and extension projects and install their dependencies for you.
+The CLI can also help you generate artifacts, such as controllers, for your projects.
+Once generated, the scaffold can be expanded with users' own code as needed.
+
+To use LoopBack 4's CLI, run this command:
+
+```
+npm install -g @loopback/cli
+```
+
+## Generating LoopBack projects
+
+{% include content/lb4-project-commands.html %}
+
+## Generating LoopBack artifacts
+
+{% include content/lb4-artifact-commands.html %}