RenaiApp/CONTRIBUTING.md

Welcome, Degenerate

Nothing in this project is set in stone (even this rule). I might not know what I'm doing.

Table of Content:

1. Currently Most Wanted
2. Communication
3. Development
   1. Environment Setup
   2. Git
   3. Database
   4. Formatting and Linters
   5. Testing
4. Design

Currently Most Wanted

User Stories

With the help of user stories, 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.

• some initial work is already done
• feedback is especially needed on the following (the rest of the ideas folder deserves a look, too)
  • tagging system
  • multiple manga series
  • multiple story manga
  • intellectual property and parodies
• any other ideas?

GUI/Prototype

The application needs a graphical user interface. Take a look at the requirements and some inspiration (You could also supply more).

The current idea is to build the frontend with Svelte, not sure if that has relevance here.

Ideas Folder

The ideas folder 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 or write me an email.

Development

Environment Setup

Things to install:

• Node.js (this also installs npm)
• Git

Then use git to clone this repository.

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.

The npm run watch script watches files and rebuilds the app on changes.

Git

This project uses Git as its version control software. If you don't know how to use it, read a quick guide.

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:

Commit Messages

This project uses Conventional Commits with the following types:

type	description
feat	implementing a new feature or changes an existing one
remove	removing an existing feature
fix	repairing a feature which does not work correctly
refactor	reworking code so that its function does not change (but could have in unexpected ways)
update	updating dependencies and associated code changes
test	any of the above, but with tests/mocks
config	changing configuration (npm scripts, linters, build process)
meta	updating something not that is not function/testing (design, documentation, comments)
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.

Retired Types

You might find the following types in the git history but their use is discouraged in favor of another type:

type	description	replaced by
doc	updating documentation, including code comments	meta

Git Hooks

This project uses 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 functioning tests. The npm run fix script fixes all fixable errors, the tests you have to fix yourself.

Database

The application uses SQLite3 as a database, with TypeORM as an object-relation mapper.

Database Migrations

Migrations are stored in src/main/migrations and handled by typeorm. Migrations are run on app start inside database.ts.

To auto-generate a migration: node_modules/.bin/typeorm migration:generate -n <migration name> -c <connection name>

To create an empty creation which can be filled with custom migration code: node_modules/.bin/typeorm migration:create -n <migration name> -c <connection name>

To run migrations: node_modules/.bin/typeorm migration:run -c <connection name> This is also pre-defined in the npm script typeorm:migrate.

Formatting and Linters

This project uses Prettier for code formatting (and an .editorconfig which you should respect). ESLint 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. 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
• Electron specific testing is done by Spectron
• spies, stubs and mocks are provided by Sinon.JS
• HTTP server mocking is done by nock
• property based testing is made possible by fast-check

Mocks

There are 2 ways in which mocks are defined/used:

0. for external modules, in mocks
   • uses the rewiremock package
   • use this only when there is some magic happening like for electron which normally runs in its own node process
1. for own modules, just beside their test file in tests
   • 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, but it can filter via title. Use the following tags in your test titles:

• @slow when the test is particularly slow

Coverage

Code coverage is provided by nyc. The detailed code coverage can be found here after running the coverage script npm run coverage (open in browser). The coverage script is separate because it does not allow simple debugging.
The code coverage does not work with Spectron since that runs in its own node process.

Design

Before implementation comes design (at least for a bit, until they run in parallel). The workspace folder is the space where all the documents for application design should go.