chore(release): release v2.0.0

Author: gamemaker1

.editorconfig

@@ -0,0 +1,13 @@
+# Top-most editor config file
+root = true
+
+# Unix-style newlines with a newline ending every file
+[*]
+end_of_line = lf
+insert_final_newline = true
+
+# Set default charset and tab length
+[*.{js, json}]
+charset = utf-8
+indent_style = tab
+tab_width = 2

.github/ISSUE_TEMPLATE/bug_report.md

@@ -30,7 +30,7 @@ If applicable, add screenshots to help explain your problem.
 
 - Dabbu Version: (Current version, seen when server is run) e.g. 1.8.0
 - OS Version: (Platform and Version) e.g. macOS 10.15.7 / Windows 10 (20H2) / Ubuntu 20.04.3 x64 / etc
-- Provider ID: hard_drive / google_drive / one_drive / gmail / etc
+- Provider ID: hard-drive / google-drive / one-drive / gmail / etc
 
 **Additional context**
 

.github/workflows/ci.yml

@@ -3,11 +3,11 @@ name: NodeJS CI
 # Triggers the workflow on push or pull request events but only for the main branch
 on: [push, pull_request]
 
-# This workflow contains three jobs: check code style, build and release
+# This workflow contains three jobs: run tests, build and release
 jobs:
-  # Check code style
-  check-format:
-    name: Check code style
+  # Run tests
+  test:
+    name: Run tests (node ${{ matrix.node_version }})
     runs-on: ubuntu-latest
     strategy:
       matrix:
@@ -22,12 +22,11 @@ jobs:
         uses: actions/setup-node@v1
         with:
           node-version: ${{ matrix.node_version }}
-      # Check the format
-      - name: Check format
+      # Run all tests
+      - name: Run tests
         run: |
           npm ci
-          npm run check-format
-
+          npm test
   # Build the executable
   build:
     name: Build executable (alpine, linux, macos, win) (node ${{ matrix.node_version }})
@@ -76,7 +75,7 @@ jobs:
   release:
     name: Upload release
     # Make sure the format and build tasks have succeeded before uploading a release
-    needs: [check-format, build]
+    needs: [test, build]
     runs-on: ubuntu-latest
     steps:
       # Checks-out the repository under $GITHUB_WORKSPACE, so we job can access it
@@ -110,31 +109,15 @@ jobs:
           echo "::set-output name=version::$version_name"
           echo "::set-output name=previous_version::$previous_version_name"
         id: check-version
-      # Get a list of all commits from the previous release till this one, and add it to the changelog
-      - name: Generate changelog
-        # Run it only if the version has been changed
-        if: ${{ steps.check-version.outputs.version != steps.check-version.outputs.previous_version }}
-        run: |
-          revision=`git rev-list --tags --max-count=1`
-          version_name=`cat version`
-          previous_version_name=`git describe --tags --abbrev=0`
-          echo "" >> CHANGELOG.md
-          echo "### Commits since last release:" >> CHANGELOG.md
-          git log --format="- %s %h" $revision..HEAD >> CHANGELOG.md
-          echo "" >> CHANGELOG.md
-          echo "Generated following CHANGELOG:"
-          cat CHANGELOG.md
-          echo "::set-output name=version::$version_name"
-          echo "::set-output name=previous_version::$previous_version_name"
-        id: generate-changelog
       - name: Create release
         # Run it only if the version has been changed
-        if: ${{ steps.generate-changelog.outputs.version != steps.generate-changelog.outputs.previous_version }}
+        if: ${{ steps.check-version.outputs.version != steps.check-version.outputs.previous_version }}
         uses: softprops/action-gh-release@v1
         with:
-          body_path: CHANGELOG.md
-          tag_name: ${{ steps.generate-changelog.outputs.version }}
-          name: Dabbu Files API Server ${{ steps.generate-changelog.outputs.version }}
+          body_path: RELEASE-NOTES.md
+          tag_name: ${{ steps.check-version.outputs.version }}
+          prerelease: contains(steps.check-version.outputs.version, '-')
+          name: Dabbu Files API Server ${{ steps.check-version.outputs.version }}
           files: |
             files-api-server-alpine
             files-api-server-linux

.gitignore

@@ -3,4 +3,4 @@ creds/
 dist/
 _dabbu/
 .git/
-.heroku*
+.heroku/

.prettierignore

@@ -1,7 +1,31 @@
-### Maintenance
+### Changes to server
 
-- Enable `dependabot`.
-- Update the following dependencies:
-  - `pkg`
-  - `file-type`
-  - `archiver`
+- Separate server code from argument parsing
+
+### Provider specific changes
+
+#### Hard Drive
+
+**Bug fixes:**
+
+- return 404 instead of 500 if file was not found 73c6d28
+- throw error if base_path is missing c210a81
+
+### Code Style
+
+- Add `XO` as linter 0ac7e22
+- Run `prettier` through `XO` to format files b11a58c
+
+### Testing
+
+- Add test framework (`ava`) 0c70860
+
+
+### Builds and CI
+
+- Add support for prereleases from the `develop` branch f707e46
+
+### Documentation
+
+- Add badges to README
+- Update CONTRIBUTING instructions

.prettierrc

@@ -51,21 +51,72 @@ Once you've built the project locally, you're ready to start making changes!
 
 ### Step 3: Branch
 
-To keep your development environment organized, create local branches to hold your work. These should be branched directly off of the `main` branch. While naming branches, try to name it according to the bug it fixes or the feature it adds.
+To keep your development environment organized, create local branches to hold your work. These should be branched directly off of the `develop` branch. While naming branches, try to name it according to the bug it fixes or the feature it adds. Also prefix the branch with the type of change it is making. Here is a list of common prefixes:
+
+- `fix/`: A bug fix
+- `feature/`: A new feature
+- `docs/`: Documentation changes
+- `perf/`: A code change that improves performance
+- `refactor/`: A code change that neither fixes a bug nor adds a feature
+- `test/`: A change to the tests
+- `style/`: Changes that do not affect the meaning of the code (linting)
+- `build/`: Bumping a dependency like node or express
 
 ```sh
-$ git checkout -b add-awesome-new-feature -t upstream/main
+$ git checkout -b feature/add-awesome-new-feature -t upstream/develop
 ```
 
 ### Step 4: Code
 
-To get a decent idea of how the code is organised and what happens where, the code is heavily commented to allow you to understand exactly what happens. Remember to always format the code using `prettier` once you're done.
+To get a decent idea of how the code is organised and what happens where, the code is heavily commented to allow you to understand exactly what happens. Remember to always format the code using `xo` once you're done.
 
 To test a change without building the executables, you can type `npm start` and it will run the server directly. Use an HTTP client like `httpie` or `postman` to test the API.
 
-To check if the code is formatted correctly, run `npm run check-format`. To format the code using prettier, run `npm run format`.
+### Step 5: Document
+
+Once your changes are ready to go, begin the process of documenting your code. The code **must** be heavily commented, so future contributors can move around and make changes easily.
+
+Make sure all the changes you make are in accordance with the [Files API Specifications](https://dabbu-knowledge-platform.github.io/files_api/). If you wish to make changes to the API specification itself, drop a message [here](https://github.com/dabbu-knowledge-platform/cli/discussions/categories/general) and we can start discussing the changes.
+
+### Step 6: Test
+
+Please ensure that all changes/additions come with tests. All PRs must have unit tests unless the maintainer says the PR is text-exempt.
+
+If you are adding a new module, add the tests for that module in the `tests/module-tests/<provider id>-test.js`. If you added a utility function, add a test for it in `tests/utils-test.js`. If you modified the handling of an internal method such as the `cache` method, or listing, enabling and disabling providers, add the test to `tests/server-test.js`.
+
+Before submitting your changes, please run the linter (`xo`) and all tests in the `tests/` folder:
+
+```
+npm test
+```
+
+Please ensure that:
+
+- your code passes all lint checks (`xo`)
+- your code passes all format checks (`prettier` run by xo) 
+- all existing and added tests pass. If the linter points out errors, try fixing them automatically by running:
+
+```
+npm run format
+```
+
+The linter will try its best to fix all issues, but certain issues require you to fix them manually.
+
+If you need to disable any lint rules, please make sure that it is really necessary and there is absolutely no better way of writing that piece of code. Disable lint checks for a certain line by entering typing the following before that line:
+
+```
+// eslint-disable-next-line some-lint-rule-id
+```
+
+To disable lint checks for an entire file (not recommended), enter the following at the top of the file:
+
+```
+/* eslint some-lint-rule-id: 0 */
+```
+
+All existing and added tests **MUST** pass for the PR to land. If existing tests are already failing on the `develop` branch, ensure that no additional tests fail due to your changes. Note that **no PRs will be merged until the tests on the `develop` branch are fixed and all of them pass**.
 
-### Step 5: Commit
+### Step 7: Commit
 
 It is recommended to keep your changes grouped logically within individual commits. Many contributors find it easier to review changes that are split across multiple commits. There is no limit to the number of commits in a pull request.
 
@@ -96,8 +147,9 @@ Common prefixes:
 - `docs`: Documentation changes
 - `perf`: A code change that improves performance
 - `refactor`: A code change that neither fixes a bug nor adds a feature
+- `test`: A change to the tests
 - `style`: Changes that do not affect the meaning of the code (linting)
-- `vendor`: Bumping a dependency like node or express
+- `build`: Bumping a dependency like node or express
 
 Other things to keep in mind when writing a commit message:
 
@@ -113,33 +165,23 @@ A commit that has the text `BREAKING CHANGE:` at the beginning of its optional b
 
 See [conventionalcommits.org](https://conventionalcommits.org) for more details.
 
-### Step 6: Rebase
+### Step 8: Rebase
 
-Once you have committed your changes, it is a good idea to use `git rebase` (_NOT `git merge`_) to synchronize your work with the main repository.
+Once you have committed your changes, it is a good idea to use `git rebase` (NOT `git merge`) to synchronize your work with the develop branch.
 
 ```sh
 $ git fetch upstream
-$ git rebase upstream/main
+$ git rebase upstream/develop
 ```
 
-This ensures that your working branch has the latest changes from `dabbu-knowledge-platform/files-api-server` main.
-
-### Step 7: Test
-
-Bug fixes and features should always come with tests. Please test your own code adequately. Also, before finally pushing your code, clone it into a fresh environment (different user or maybe a different computer) and make sure it works just as fine. Make sure you test the executables in the `dist/` directory.
-
-### Step 8: Document
-
-Once your commits are ready to go - with adequate testing - begin the process of documenting your code. The code **must** be heavily commented, so future contributors can move around and make changes easily.
-
-Make sure all the changes you make are in accordance with the [Files API Specifications](https://dabbu-knowledge-platform.github.io/files_api/). If you wish to make changes to the API specification itself, drop a message [here](https://github.com/dabbu-knowledge-platform/cli/discussions/categories/general) and we can start discussing the changes.
+This ensures that your working branch has the latest changes from `dabbu-knowledge-platform/files-api-server` develop. If any conflicts arise, resolve them and commit the changes again.
 
 ### Step 9: Push
 
 Once you have documented your code as required, begin the process of opening a pull request by pushing your working branch to your fork on GitHub.
 
 ```sh
-$ git push origin add-awesome-new-feature
+$ git push origin feature/add-awesome-new-feature
 ```
 
 ### Step 10: Opening the Pull Request
@@ -155,21 +197,21 @@ To make changes to an existing pull request, make the changes to your local bran
 ```sh
 $ git add my/changed/files
 $ git commit
-$ git push origin add-awesome-new-feature
+$ git push origin feature/add-awesome-new-feature
 ```
 
-There are a number of more advanced mechanisms for managing commits using `git rebase` that can be used, but are beyond the scope of this guide.
+There are a number of more advanced mechanisms for managing commits using `git rebase` that can be used, but are beyond the scope of this guide. Also, any branch that is being merged must be merged without fast forward, i.e., `git merge --no-ff ...`.
 
 Feel free to post a comment in the pull request to ping reviewers if you are awaiting an answer on something.
 
 **Approval and Request Changes Workflow**
 
-All pull requests require approval from contributors in order to land. Whenever a maintainer reviews a pull request they may request changes. These may be small, such as fixing a typo, or may involve substantive changes. Such requests are intended to be helpful, but at times may come across as abrupt or unhelpful, especially if they do not include concrete suggestions on _how_ to change them.
+All pull requests require approval from at least one maintainer in order to land. Whenever a maintainer reviews a pull request they may request changes. These may be small, such as fixing a typo, or may involve substantive changes. Such requests are intended to be helpful, but at times may come across as abrupt or unhelpful, especially if they do not include concrete suggestions on _how_ to change them.
 
 Try not to be discouraged. Try asking the maintainer for advice on how to implement it. If you feel that a review is unfair, say so or seek the input of another project contributor. Often such comments are the result of a reviewer having taken insufficient time to review and are not ill-intended. Such difficulties can often be resolved with a bit of patience. That said, reviewers should be expected to provide helpful feedback.
 
 ### Step 12: Landing
 
-In order to land, a pull request needs to be reviewed and approved by at least one contributor. After that, if there are no objections from other contributors, the pull request can be merged.
+In order to land, a pull request needs to be reviewed and approved by at least one maintainer. After that, if there are no objections from other contributors, the pull request can be merged.
 
 **Congratulations and thanks a lot for your contribution!**

CHANGELOG.md

@@ -1 +1 @@
-web: npm start $PORT google_drive one_drive gmail
+web: npm start $PORT google-drive one-drive gmail

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Dabbu Files API Server
 
-[![NodeJS CI](https://github.com/dabbu-knowledge-platform/files-api-server/actions/workflows/ci.yml/badge.svg)](https://github.comdabbu-knowledge-platform/files-api-server/actions/workflows/ci.yml)
+[![NodeJS CI](https://github.com/dabbu-knowledge-platform/files-api-server/actions/workflows/ci.yml/badge.svg)](https://github.com/dabbu-knowledge-platform/files-api-server/actions/workflows/ci.yml) [![Platforms: Alpine Linux MacOS Windows](https://img.shields.io/badge/platforms-alpine%20linux%20macos%20windows-blue)](https://img.shields.io/badge/platforms-windows%20linux%20macos%20alpine-blue) [![Code Style: XO/Prettier](https://img.shields.io/badge/code%20style-xo%2Fprettier-ff69b4)](https://img.shields.io/badge/code%20style-xo%2Fprettier-ff69b4)
 
 An implementation of the Dabbu Files API that enables you to access your files, folders and emails stored with multiple providers as simple files and folders, all in one place!
 
@@ -34,10 +34,10 @@ Here is a list of clients that use the Dabbu API to interact with your files and
 
 ## Supported Providers
 
-- [**Hard drive**](./docs/modules/hard_drive.md)
-- [**Google drive**](./docs/modules/google_drive.md)
-- [**Gmail**](./docs/modules/gmail.md)
-- [**One drive**](./docs/modules/one_drive.md)
+- **Hard drive**
+- **Google drive**
+- **Gmail**
+- **One drive**
 
 _And more to come...!_