# setup
yarn && yarn prepare
# development server
yarn dev
# create production build
yarn build
# serve production build
yarn start
# run tests
yarn test
# run lints
yarn lint
# run typecheck
yarn typecheck
They are served in different variations of .env
files:
- For local environment we use
.env.local
Deployment is done via GitHub Actions. Whole configuration resides in YAML files inside .github/workflows
directory.
- All code pushed to
develop
branch is deployed todev.openphilology.eu
; - All code pushed to
main
branch is deployed tostaging.openphilology.eu
;
To add/change/remove environment variables you need to access the machine Dokku is running on via SSH. Access details are in 1password vault. Once you're in, please use Dokku CLI commands.
Dokku uses Heroku Buildpacks under the hood. If apps node.js/npm/yarn versions are upgraded, please remember to also update them inside package.json engines
section.
Keep an eye on the guidelines while submitting your PRs and while reviewing others' to assure code quality and consistency in the project.
- Use snapshots only for base UI components like buttons or form controls.
- Use
styled-components
for styling and use theme as the source of truth for colors, borders and typography. Do not use inline styles or CSS files. When you import a components and you want to apply styles on top of it (and you can't think of a meaningful name), you can use the following convention:
import BaseButton from "./button";
const Button = styled(BaseButton)`
...
`;
- Prefer function keyword for component and hook names and arrow function for everything else like callbacks and event handlers.
- Always prefer functional components except really rare scenario where you need access methods of React component that are not available in a functional component.
- Write texts as translation strings only, see public/locales/en/common.json.
- Do not nest ternaries.
- Prefer early return whenever possible, see example:
// Without early return
const myFunction = function () {
if (myCondition) {
// some other stuff
return stuff;
}
return null;
};
// With early return
const myFunction = function () {
if (!myCondition) return null;
// some other stuff
};
- Do not violate HTML principles when writing JSX and keep an eye on accessibility, you can use helper tools like Lighthouse audit or aXe devtools extension.
- Prefer
hooks
for reusing logic, do not useRender Props
, do not useHOC
. - Feel free to suggest your own guidelines on the fly as basis for future development and code reviews.
- We squash PRs so you don't need to follow any specific commit convention while working on them, however, when you want to merge your PR the PR title has to follow a specific convention. It starts with the Jira issue ID in square brackets, followed by colon and a short message. Then use a line-break and write a more detailed description for the issue (or the text-area if merging through github). See example below:
[OPLU-103]: project setup
This PR introduces base conventions, core library setup and initial project structure.
- Use naming convention for branches suggested by Jira
OPLU-103-project-setup
- Name constants in UPPER_SNAKE_CASE.
- In hooks directory, store only hooks that are used more than once, do not store feature-specific hooks there, such hooks belong to their feature.
- For working with static forms use react-hook-form and zod, see example. For dynamic forms use what suits the use case best.
- Every request should be tested and mocked using MSW.
- Everything related to
react-testing-library
is imported from test-utils. - Always use meaningful variables, avoid abbreviations or single-character variable names
- Prefer types to interfaces for type declarations.
- Use curly braces for multi-line ifs, even if there is only a single instruction inside.