First and foremost, thank you! We appreciate that you want to contribute to Synectic, your time is valuable, and your contributions mean a lot to us.
Do not create issues about bumping dependencies unless a bug has been identified, and you can demonstrate that it effects this project. Synectic is a desktop application, and therefore is not subject to the same security concerns as web applications. However, we do take security seriously, and will address any security concerns that are identified.
Remember that we’re here to help, but not to make guesses about what you need help with:
- Whatever bug or issue you're experiencing, assume that it will not be as obvious to the maintainers as it is to you.
- Spell it out completely. Keep in mind that maintainers need to think about all potential use cases of a library. It's important that you explain how you're using a library so that maintainers can make that connection and solve the issue.
It can't be understated how frustrating and draining it can be to maintainers to have to ask clarifying questions on the most basic things, before it's even possible to start debugging. Please try to make the best use of everyone's time involved, including yourself, by providing this information up front.
Setup your development environment by following the Development instructions in the README.
All development should occur in branches (or forks) and be submitted as a Pull Request (PR) back to the main branch. The following steps represent the preferred workflow, and include details about contribution requirements:
- Create a feature or bugfix branch with a name that is representative of the development purpose (e.g.
feature/drag-n-highlight,fix/ghosting_images,feature/pixel-comparison). Names that reference issue numbers, usernames, or random animals are not acceptable naming conventions. - Develop code and commit to the new branch with commit messages that provide context for underlying changes contained within each commit. Avoid platform dependent code.
- When development is complete, and all requirements listed in any associated issues have been met, submit a PR to the
mainbranch. Include a bulleted list of contribution features/bugfixes/alterations in the PR description. Do not include issue numbers in the PR title. Do try to use the Linked issues feature in GitHub to link the pull request to the related issue(s). - Review the results of continuous integration via GitHub Actions. Pull Requests will not be accepted unless all tests are passing for that branch.
- Wait for a code review from at least one other developer on the project. Address any changes requested during the review in order to gain approval.
- Once merged, make updates to any related issues as needed for status tracking.
Several sections of the Synectic API include advanced TypeScript features and the codebase can be difficult to understand for a newcomer, therefore the following references are compiled here for reading as needed:
- TypeScript Handbook: Generics
- TypeScript Handbook: Narrowing
- TypeScript Handbook: JSX
- TypeScript Deep Dive: Arrow Functions
- TypeScript Deep Dive: Rest Parameters
- TypeScript Deep Dive: Type Assertion
- TypeScript Deep Dive: Type Guard
- Using
Async/Awaitwith Typescript Classes - Keep Your Promises in TypeScript using
async/await - Asynchronous Processing with TypeScript and Generic Promises
React and Redux:
- Hooks API Reference
- Using the React useContext Hook
- Idiomatic Redux: Why use action creators?
- ES6 Map with React.useState
- Understanding the React useMemo Hook
- How to Persist Your Redux Store
Jest Testing:
- Taking Advantage of Jest Matchers (Part 1)
- Taking Advantage of Jest Matchers (Part 2)
- Jest matching objects in array
Advanced typing features in TypeScript: