docs: add CONTRIBUTING, DEVELOPING and VSCODE

Add a short CONTRIBUTING.md file serving as a collection of links
pointing to other documentation.

Start a guide for developers in DEVELOPING.md.

Describe VS Code setup in VSCODE.md, document steps needed to verify
integration with tsc and tslint.

Add docs/apidocs.html as an index file pointing to apidoc files of
individual monorepo packages.

CONTRIBUTING.md

@@ -0,0 +1,40 @@
+# Contributing to LoopBack
+
+Contributions to LoopBack include code, documentation, answering user questions, and advocating for all types of LoopBack users. See our official documentation on loopback.io for more information common to all of our GitHub repositories:
+
+  - http://loopback.io/doc/en/contrib/index.html
+
+## [Principles](http://loopback.io/doc/en/contrib/Governance.html#principles)
+
+LoopBack is an open, inclusive, and tolerant community of people working together to build a world-class Node framework and tools. We value diversity of individuals and opinions, and seek to operate on consensus whenever possible. We strive to maintain a welcoming, inclusive, and harassment-free environment, regardless of the form of communication. When consensus is not achievable, we defer to the owners of each individual module; the powers of the individual owner are kept in check by the ability of the community to fork and replace dependencies on the individual module and maintainer.
+
+## [Reporting issues](http://loopback.io/doc/en/contrib/Reporting-issues.html)
+
+Issues in [strongloop/loopback-next](https://github.com/strongloop/loopback-next/issues) are the primary means by which bug reports and general discussions are made.
+
+ - [How to report an issue](http://loopback.io/doc/en/contrib/Reporting-issues.html#how-to-report-an-issue)
+ - [Disclosing security vulnerabilities](http://loopback.io/doc/en/contrib/Reporting-issues.html#security-issues)
+
+## [Contributing code](http://loopback.io/doc/en/contrib/code-contrib.html)
+
+Pull Requests are the way concrete changes are made to the code, documentation and tools contained in LoopBack repositories.
+
+ - [Setting up development environment](./docs/DEVELOPING.md#setting-up-development-environment)
+ - [How to contribute the code](http://loopback.io/doc/en/contrib/code-contrib.html#how-to-contribute-to-the-code)
+ - [Building the project](./docs/DEVELOPING.md#building-the-project)
+ - [Running tests](./docs/DEVELOPING.md#running-tests)
+ - [Coding rules](./docs/DEVELOPING.md#coding-rules)
+ - [API documentation](./docs/DEVELOPING.md#api-documentation)
+ - [Git commit messages](./docs/DEVELOPING.md#commit-message-guidelines)
+ - [Reviewing pull requests](http://loopback.io/doc/en/contrib/triaging-pull-requests.html)
+ - [Contributor License Agreement (CLA)](http://loopback.io/doc/en/contrib/code-contrib.html#agreeing-to-the-cla)
+
+## [Documentation](http://loopback.io/doc/en/contrib/doc-contrib.html)
+
+LoopBack documentation is sourced in the [strongloop/loopback.io](https://github.com/strongloop/loopback.io) GitHub repository.
+
+ - [How LoopBack documentation works](http://loopback.io/doc/en/contrib/doc-contrib.html#how-loopback-documentation-works)
+ - [Using Jekyll](http://loopback.io/doc/en/contrib/jekyll_getting_started.html)
+ - [Authoring pages](http://loopback.io/doc/en/contrib/pages.html)
+ - [Translations](http://loopback.io/doc/en/contrib/translation.html)
+

docs/DEVELOPING.md

@@ -0,0 +1,194 @@
+# Developing LoopBack
+
+This document describes how to develop modules living in loopback-next monorepo.
+
+ - [Setting up development environment](#setting-up-development-environment)
+ - [Building the project](#building-the-project)
+ - [Running tests](#running-tests)
+ - [Coding rules](#coding-rules)
+ - [API documentation](#api-documentation)
+ - [Commit message guidelines](#commit-message-guidelines)
+ - [How to test infrastructure changes](#how-to-test-infrastructure-changes)
+
+## Setting up development environment
+
+Before you can start developing LoopBack, you need to install and configure few
+dependencies.
+
+ - [git](https://git-scm.com/): Github's [Set Up Git](https://help.github.com/articles/set-up-git/) guide is a good source of information.
+ - [Node.js 8.x (LTS)](https://nodejs.org/en/download/)
+
+You may want to configure your IDE or editor to get better support for
+TypeScript too.
+
+ - [VisualStudio Code](./VSCODE.md)
+ - _Missing your favorite IDE/editor here? We would love to have documentation for more IDEs/editors! Please send a pull request to add recommended setup for your tool._
+
+Before getting started, it is recommended to configure `git` so that it knows who you are:
+
+```sh
+$ git config --global user.name "J. Random User"
+$ git config --global user.email "[email protected]"
+```
+
+Please make sure this local email is also added to your [GitHub email list](https://github.com/settings/emails) so that your commits will be properly associated with your account and you will be promoted to Contributor once your first commit is landed.
+
+## Building the project
+
+Whenever you pull updates from GitHub or switch between feature branches,
+we recommend to do a full reinstall of all npm dependencies:
+
+```sh
+$ npm run clean:lerna && npm run bootstrap
+```
+
+The next step is to compile all packages from TypeScript to JavaScript:
+
+```sh
+$ npm run build
+```
+
+Please note that we are automatically running the build from `pretest`
+script, therefore you should not need to run this command as part of your
+[red-green-refactor cycle](http://www.jamesshore.com/Blog/Red-Green-Refactor.html).
+
+## Running tests
+
+This is the only command you should need while developing LoopBack:
+
+```sh
+$ npm test
+```
+
+It does all you need:
+
+ - Compile TypeScript
+ - Run all tests
+ - Check code formatting using [Prettier](https://prettier.io/)
+ - Lint the code using [TSLint](https://palantir.github.io/tslint/)
+
+## Coding rules
+
+- All features and bug fixes must be covered by one or more automated tests.
+
+- All public methods must be documented with typedoc comments (see [API Documentation](#api-documentation) below).
+
+- Code should be formatted using [Prettier](https://prettier.io/), see our [prettierrc](../prettierrc).
+
+- Follow our style guide as documented on loopback.io: [Code style guide](http://loopback.io/doc/en/contrib/style-guide.html).
+
+## API Documentation
+
+We use [strong-docs](https://github.com/strongloop/strong-docs) to generate API documentation for all our packages. This documentation is generated when publishing new releases to npmjs.org and it's picked up by http://apidocs.loopback.io/.
+
+You can preview API docs locally by opening the file `docs/apidocs.html` in your browser.
+
+## Commit message guidelines
+
+_Note: we have recently changed our commit message conventions. Most of other LoopBack repositories (e.g. [strongloop/loopback.io](https://github.com/strongloop/loopback.io)) use the older convention as described on [loopback.io](https://loopback.io/doc/en/contrib/git-commit-messages.html)._
+
+A good commit message should describe what changed and why.
+
+Our commit messages are formatted according to [Conventional Commits](https://conventionalcommits.org/), we use [commitlint](https://github.com/marionebl/commitlint) to verify and enforce this convention.  These rules lead to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate change logs when publishing new versions.
+
+### Commit Message Format
+
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, an optional **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+#### type
+
+The **type** must be one of the following:
+
+ - **feat**: A new feature
+ - **fix**: A bug fix
+ - **docs**: Documentation only changes
+ - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+ - **refactor**: A code change that neither fixes a bug nor adds a feature
+ - **perf**: A code change that improves performance
+ - **test**: Adding missing or correcting existing tests
+ - **build**: Changes that affect the build system or external dependencies
+ - **ci**: Changes to our CI configuration files and scripts
+ - **chore**: Changes to the auxiliary tools and libraries such as documentation generation
+ - **revert**: Reverts a previous commit
+
+#### scope
+
+The **scope** must be a list of one or more packages contained in this monorepo. Each scope name must match a directory name in [packages/](../packages), e.g. `core` or `context`.
+
+
+#### subject
+
+The **subject** contains succinct description of the change:
+
+ - use the imperative, present tense: "change" not "changed" nor "changes"
+ - don't capitalize first letter
+ - no dot (.) at the end
+
+#### body
+
+The **body** provides more details, it should include the motivation for the change and contrast this with previous behavior.
+
+Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"a
+
+#### footer (optional)
+
+The **footer** should contain any information about Breaking Changes introduced by this commit.
+
+This section must start with the upper case text `BREAKING CHANGE` followed by a colon (`:`) and a space (` `). A description must be provided, describing what has changed and how to migrate from older versions.
+
+## How to test infrastructure changes
+
+When making changes to project infrastructure, e.g. modifying `tsc` or `tslint`
+configuration, it's important to verify that all usage scenarios keep working.
+
+### Verify TypeScript setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Add a small bit of code to break TypeScript's type checks, for example:
+
+    ```ts
+    const foo: number = 'bar';
+    ```
+
+3. Run `npm test`
+
+4. Verify that the build failed and the compiler error message shows a path
+   relative to monorepo root, e.g. `packages/src/index.ts`.
+
+   _(This is does not work now, `tsc` is reporting paths relative to individual package directories. See https://github.com/strongloop/loopback-next/issues/1010)_
+
+5. Test integration with supported IDEs:
+    - [VS Code](./VSCode.md#how-to-verify-typescript-setup)
+
+### Verify TSLint setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Introduce two kinds linting problems - one that does and another that does not require type information to be detected. For example, you can add the following line at the end of the opened `index.ts`:
+
+    ```ts
+    const foo: any = 'bar';
+    ```
+
+3. Run `npm test`
+
+4. Verify that the build failed and both linting problems are reported:
+
+    ```text
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 7]: 'foo' is declared but its value is never read.
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 12]: Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type.
+    ```
+
+5. Test integration with supported IDEs:
+
+    - [VS Code](./VSCode.md#how-to-verify-tslint-setup)
+

docs/VSCODE.md

@@ -0,0 +1,93 @@
+# Developing with VisualStudio Code
+
+We recommend our contributors to use [VisualStudio Code](https://code.visualstudio.com/) with the following extensions installed:
+ - [Prettier - Code Formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) for automatic formatting of source files on save.
+ - [TSLint](https://marketplace.visualstudio.com/items?itemName=eg2.tslint) to highlight and auto-fix linting problems directly in the editor.
+
+Our monorepo comes with few preconfigured [VSCode
+Tasks](https://code.visualstudio.com/docs/editor/tasks):
+
+ - The build task is configured to run the TypeScript compiler
+ - The test task is configured to run `npm test` (which runs the build before running any tests).
+
+## How to verify TypeScript setup
+
+### Compilation errors
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Add a small bit of code to break TypeScript's type checks, for example:
+
+    ```ts
+    const foo: number = 'bar';
+    ```
+
+3. Verify that VS Code editor has marked `foo` with a red underscore. Hover over `foo` and check the problem message. It should mention `[ts]` source, e.g.
+
+    ```text
+    [ts] Type '"bar"' is not assignable to type 'number'.
+
+    ```
+
+4. Check VS Code's [PROBLEMS Window](https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_errors-and-warnings).  There should be an entry showing the same tslint error. When you click on the entry, it should jump on the problematic line.
+
+5. Close the editor tab. (This will clear the PROBLEMS entry reported by TSLint extension).
+
+6. Run the test task ("Tasks: Run test task"). This will invoke package scripts like `npm test` under the hood.
+
+7. Open "Tasks" OUTPUT window and verify that compilation error was parsed by VSCode.
+
+8. Verify that compilation errors are correctly associated with the problematic source code line.
+   _(This is does not work now, `tsc` is reporting paths relative to individual package directories. See https://github.com/strongloop/loopback-next/issues/1010)_
+
+### Navigation in VS Code
+
+Verify that "Go to definition" works across package boundaries.  Find a place where we are calling `@inject` in `authentication` package, press F12 to go to the definition of `inject`. VSCode should jump to the `.ts` file in `src` (as opposed to jumping to a `.d.ts` file in `dist`)
+
+#### Refactoring in VS Code
+
+Verify that refactorings like "rename symbol" (`F2`) will change all places using the renamed entity. Two different scenarios to verify: rename at the place where the entity is defined, rename at the place where the entity is used. (You can e.g. rename `inject` to test.)
+
+## How to verify TSLint setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Verify that TSLint extension is not reporting any warnings in the output
+   window:
+    - pres _Cmd+shift+P_ or _Ctrl+shift+P_ to open task selector
+    - find and run the task `TSLint: Show Output`
+    - check the logs
+
+    An example of a warning we want to **avoid**:
+
+    ```text
+    Warning: The 'no-unused-variable' rule requires type information.
+    ```
+
+3. Introduce two kinds linting problems - one that does and another that does not require type information to be detected. For example, you can add the following line at the end of the opened `index.ts`:
+
+    ```ts
+    const foo: any = 'bar';
+    ```
+
+4. Verify that VS Code editor has marked `any` with a red underscore. Hover over `any` and check the problem message. It should mention `no-any` rule, e.g.
+
+    ```text
+    [tslint] Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type. (no-any)
+    ```
+
+5. Check VS Code's [PROBLEMS Window](https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_errors-and-warnings).  There should be an entry showing the same tslint error. When you click on the entry, it should jump on the problematic line.
+
+6. Close the editor tab. (This will clear the PROBLEMS entry reported by TSLint extension).
+
+7. Run the test task ("Tasks: Run test task"). This will invoke package scripts like `npm test` under the hood.
+
+8. Open "Tasks" OUTPUT window and verify that two tslint problems were reported:
+
+    ```text
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 7]: 'foo' is declared but its value is never read.
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 12]: Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type.
+    ```
+
+9. Open "PROBLEMS" window again. Verify that both problems were parsed by VS Code and are correctly associated with the problematic source code line.
+

docs/apidocs.html

@@ -0,0 +1,33 @@
+<html>
+<head>
+  <meta charset="utf-8">
+  <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
+  <title>LoopBack API Documentation (local)</title>
+  <link rel="stylesheet" href="http://apidocs.loopback.io/css/bootstrap.min.css">
+  <link rel="stylesheet" href="http://apidocs.loopback.io/css/code-themes/sl-theme.css">
+  <link rel="stylesheet" href="http://apidocs.loopback.io/css/main.css">
+</head>
+<body>
+  <div class="col-lg-9 reset-home-content">
+    <div id="LoopBack4">
+      <h2>LoopBack4 packages (local)</h2>
+
+      <p>Run the following command to (re)build API doc files:
+      <p><pre><code>$ npx lerna run build:apidocs</code></pre>
+
+      <h3>List of packages</h3>
+      <ul>
+        <li><a href="../packages/authentication/api-docs/index.html">@loopback/authentication</a></li>
+        <li><a href="../packages/context/api-docs/index.html">@loopback/context</a></li>
+        <li><a href="../packages/core/api-docs/index.html">@loopback/core</a></li>
+        <li><a href="../packages/metadata/api-docs/index.html">@loopback/metadata</a></li>
+        <li><a href="../packages/openapi-spec/api-docs/index.html">@loopback/openapi-spec</a></li>
+        <li><a href="../packages/openapi-spec-builder/api-docs/index.html">@loopback/openapi-spec-builder</a></li>
+        <li><a href="../packages/openapi-v2/api-docs/index.html">@loopback/openapi-v2</a></li>
+        <li><a href="../packages/repository/api-docs/index.html">@loopback/repository</a></li>
+        <li><a href="../packages/rest/api-docs/index.html">@loopback/rest</a></li>
+      </ul>
+    </div>
+  </div>
+</body>
+</html>