With the help of [user stories](workspace/user-stories.md), one is able to formulate requirements for the application which then can be implemented. This also includes the design of a GUI.
### Database Schema
Based on the user stories, features, and feature ideas, one of the next steps is to design a [database schema](workspace/schema).
- some initial work is already done
- feedback is especially needed on the following (the rest of the [ideas folder](workspace/ideas) deserves a look, too)
- [multiple manga series](workspace/ideas/multi-work-series.md)
- [multiple story manga](workspace/ideas/multi-story-manga.md)
- [intellectual property and parodies](workspace/ideas/ip-and-parody.md)
- any other ideas?
### GUI/Prototype
The application needs a graphical user interface. Take a look at the [requirements](workspace/gui/requirements.md) and some [inspiration](workspace/gui/inspiration) (You could also supply more).
The current idea is to build the frontend with [Svelte](https://svelte.dev), not sure if that has relevance here.
### Ideas Folder
The [ideas folder](workspace/ideas) is a collection of possible features for the application. Feedback and discussion is wanted for every idea.
## Communication
Every contribution is valuable. Open a ticket [here](https://git.fuwafuwa.moe/Xymorot/RenaiApp/issues) or write me an [email](mailto:xymorot@mailbox.org).
Then [use git to clone this repository](https://www.google.com/search?q=how+to+clone+a+repository+with+git).
Run `npm install` in a terminal window opened to the cloned repository, all dependencies will be installed. You might be required to install external build tools (especially if under Windows) for the compilation of native node modules, mainly sqlite3.
Then run `npm run build` to build the app, and `npm start` to run it.
This project uses Git as its version control software. If you don't know how to use it, [read a quick guide](https://www.google.com/search?q=how+to+git).
The general contributing workflow is like this:
> **fork repository** > **do your changes on the fork** > **create pull request to original repository**
Once you build up enough trust, I might add you as a contributor.
Some additional care has to be taken for the following points:
| `reformat` | rewriting code in a way in which it is impossible for function to change |
Always try to split up your changes into coherent commits, a single commit should do a single thing. If your commit needs to do more than one thing it should be labeled with the type coming first in this list.
Special cases are **merge commits** and **revert commits**. Git provides a default commit message for these two cases, just leave them if you do nothing else to the committed files.
This project uses [Husky](https://github.com/typicode/husky) to define git hooks. The point of the pre-commit hook is to have a clean commits. This means correctly formatted, without linter errors, and with functioning tests. The `npm run fix` script fixes all fixable errors, the tests you have to fix yourself.
Migrations are stored in [src/main/migrations](src/main/migrations) and handled by typeorm. Migrations are run on first database connection inside [database.ts](src/main/core/database.ts).
This project uses [Prettier](https://prettier.io/) for code formatting (and an [.editorconfig](.editorconfig) which you should respect). [ESLint](https://eslint.org/) is used for linting.\
The point of these libraries is to make uniform code possible over various editors. If you are not happy with the rules, do not ignore the warnings! Understand why the rule is there (googling helps) and if you decide the rule should not be active, deactivate it. Also think about if the rule should be deactivated everywhere or not, then configure accordingly. Explain your reasoning in the commit body.
### Testing
The testing framework of choice is [Mocha](https://mochajs.org/). Call `npm run test` to run all tests. Tests are written in typescript and need to be transpiled before testing.
- assertion is (mainly) done by [Chai](https://www.chaijs.com/)
- Electron specific testing is done by [Spectron](https://electronjs.org/spectron)
- spies, stubs and mocks are provided by [Sinon.JS](https://sinonjs.org/)
- HTTP server mocking is done by [nock](https://github.com/nock/nock)
- property based testing is made possible by [fast-check](https://github.com/dubzzz/fast-check)
- name the file `*.mock.ts` and use existing mock files for orientation on how to build them
- use sparingly and only when not having a mock makes it more complex e.g. for modules which interact with the file system
#### Tagging
Mocha does [not have a separate tagging feature](https://github.com/mochajs/mocha/wiki/Tagging), but it can filter via title. Use the following tags in your test titles:
Code coverage is provided by [nyc](https://github.com/istanbuljs/nyc). The detailed code coverage can be found under `.nyc_output/coverage/index.html` (open in browser) after running the coverage script `npm run coverage`. The coverage script is separate because it does not allow simple debugging.
In the best case a simple `npm update` does the trick, but to upgrade to a new major version of a dependency a manual `npm install <package>@<version>` is necessary. All code changes to work with the new dependency must be in the same commit.
#### Electron
Updating Electron also updated the Node.js and Chromium version it uses internally. When upgrading to a new major Node version, the Node.js version in the development environment should also be updated. This also means updating the `node` version key under `engines` in [package.json](package.json).
Before implementation comes design (at least for a bit, until they run in parallel). The [workspace folder](workspace) is the space where all the documents for application design should go.
