78 lines
4.1 KiB
Markdown
78 lines
4.1 KiB
Markdown
|
|
|
|
# レンアイ - Hentai Library Thingy
|
|
|
|
## Development
|
|
|
|
### Quickstart
|
|
|
|
- `npm install`, the postinstall runs
|
|
- `npm run rebuild`
|
|
- might need to install some build tools depending on your platform
|
|
- `npm run watch` for code transpilation (starts watchers)
|
|
- `npm run start`
|
|
|
|
### Git Commits
|
|
|
|
This project uses [Conventional Commits](https://www.conventionalcommits.or) 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 directly related to function or documentation (e.g. branding) |
|
|
| `doc` | updating documentation, including code 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.
|
|
|
|
### Database Migrations
|
|
|
|
Migrations are stored in [src/main/migrations](src/main/migrations) and handled by typeorm. Migrations are run on app start inside [database.ts](src/main/services/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`.
|
|
|
|
### 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)
|
|
|
|
#### Mocks
|
|
|
|
There are 2 ways in which mocks are defined/used:
|
|
|
|
0. for external modules, in [mocks](mocks)
|
|
- uses the [rewiremock](https://github.com/theKashey/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](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 seperate tagging feature](https://github.com/mochajs/mocha/wiki/Tagging), but it can filter via title. Us the following tags in your test titles:
|
|
|
|
- `@slow` when the test is particularly slow
|
|
|
|
#### Coverage
|
|
|
|
Code coverage is provided by [nyc](https://github.com/istanbuljs/nyc). The detailed code coverage can be found [here](.nyc_output/coverage/index.html) after running the tests (open in browser).
|