What should I know before I get started?
-
Fork the repository (https://help.github.com/articles/fork-a-repo/)
-
Clone the repository to your local machine (https://help.github.com/articles/cloning-a-repository/)
$ git clone [email protected]:[username]/rsschool-app.git
- Navigate into the directory where you've cloned the source code and install NPM dependencies
$ cd rsschool-app
$ npm install
- If you plan to change the server part, please create a branch for your feature
$ git checkout -b feature-x master
- The application requires a connection to a Postgres database. Here is how to get test database running locally:
Run a Postgres Database locally using Docker & Docker Compose
$ npm run db:up
Restore a test database snapshot
$ npm run db:restore
If you are done with development, stop the database;
$ npm run db:down
- Run the application in development mode with live reload:
$ npm start
-
Do hacking 👩💻👨💻
-
You could specify any environment variable during development using
.env
file. Make a copy ofserver/.env.example
and rename it toserver/.env
. We support it viadotenv
package. More information about usage here: https://github.com/motdotla/dotenv. -
By default locally, you will be logged with
admin
access. If you want to change it, need to setRSSHCOOL_DEV_ADMIN
tofalse
in.env
file
IMPORTANT: Never commit changes to .env
file
-
Do not forget to write Jest specs for your feature following Specs Styleguide
-
Make sure specs, lints pass and code formatted properly (they'll be run on a git pre-commit hook too)
$ npm test
$ npm run lint
$ npm run pretty
- Commit your changes using a descriptive commit message that follows our commit message conventions
$ git commit -m "feat: implement feature X"
- Push your branch to GitHub:
$ git push origin feature-x
- Create a pull request
- Check how to create a pull request
- Send a pull request to
master
branch - Write a meaningful description
- Include screenshots and animated GIFs in your pull request whenever possible
- Use Conventional Commits format
- Allowed Types:
- build: - changes that affect the build system or external dependencies (example scopes: npm, webpack)
- ci: - changes to our CI configuration files and scripts (example scopes: drone)
- docs: - documentation only changes
- feat: - a new feature
- fix: - a bug fix
- perf: - a code change that improves performance
- refactor: - a code change that neither fixes a bug nor adds a feature
- style: - сhanges that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: - adding missing tests or correcting existing tests
- Use the present tense ("add feature" not "added feature")
- Use the imperative mood ("move cursor to..." not "moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
We use Prettier for TypeScript formatting. Please run the following command before your commit:
npm run pretty
For your convience, you can integrate Prettier into your favorite IDE (https://prettier.io/docs/en/editors.html)
- Name spec file by adding
.spec
to the name of tested file.
Example:
foo.ts
foo.spec.ts // spec file for foo.ts
- Treat
describe
as a noun or situation. - Treat
it
as a statement about state or how an operation changes state.
Example:
describe('Header', () => {
it('shows username', () => {
//...
})
it('shows logout button', () => {
//...
})
})