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.
Every contribution is valuable. Open a ticket [here](https://git.fuwafuwa.moe/Xymorot/RenaiApp/issues) or write me an [email](mailto:xymorot@mailbox.org).
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.
| `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.
The application uses [SQLite3](https://www.npmjs.com/package/better-sqlite3) as a database, with [TypeORM](https://typeorm.io) as an object-relation mapper.
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).
For now you need to `npm rebuild` better-sqlite3 for your local node version to run these since there is no easy way to make them work inside electron. Don't forget to run `npm run rebuild` after to rebuild for electron again.
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.
For the creation of test files look at existing ones, they are named `*.spec.ts`. They are run inside electron via [electron-mocha](https://github.com/jprichardson/electron-mocha).
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.
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.
