First off, thanks for taking the time to contribute! ❤️
All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions.
If you want to ask a question, we assume that you have read the available Documentation.
Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.
A good bug report shouldn't leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.
- Make sure that you are using the latest version.
- Determine if your bug is really a bug and not an error on your side e.g. using incompatible environment components/versions.
- Collect information about the bug:
- Stack trace (Traceback)
- OS, Platform and Version (Windows, Linux, macOS, x86, ARM)
- Version of the interpreter, compiler, SDK, runtime environment, package manager, depending on what seems relevant.
- Possibly your input and the output
- Can you reliably reproduce the issue? And can you also reproduce it with older versions?
This section guides you through submitting an enhancement suggestion for OpenFlowKit, including completely new features and minor improvements to existing functionality. Following these guidelines will help maintainers and the community to understand your suggestion and find related suggestions.
- Fork the repository on GitHub.
- Clone the project to your own machine.
- Commit changes to your own branch.
- Push your work back up to your fork.
- Submit a Pull Request so that we can review your changes.
NOTE: Be sure to merge the latest from "upstream" before making a pull request!
- 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
# Install dependencies (also activates husky pre-commit hooks)
npm install
# Start dev server
npm run dev # http://localhost:5173
# Run unit + integration tests (Vitest)
npm test
# Watch mode
npm run test:watch
# Run E2E tests (requires dev server already running)
npm run e2e
# Lint
npm run lintHusky runs lint-staged on every commit. It lints changed .ts / .tsx files with ESLint. Fix all errors before pushing — the CI gate runs the same check.
- TypeScript everywhere — avoid
any; if you must use it, add a comment explaining why. - React 19 Compiler rules:
useMemo/useCallbackdependencies must be stable store references, not inline-constructed objects. - Component size: aim for ≤ 250 lines per component. Larger components should be split (see
ARCHITECTURE.mdfor howCustomNodewas decomposed). - No new runtime dependencies without opening an issue and getting agreement first.
Gate new features behind a flag in src/config/rolloutFlags.ts:
export type RolloutFlagKey = 'myFeature' | /* … */;
export const ROLLOUT_FLAGS = {
myFeature: import.meta.env.VITE_ROLLOUT_MY_FEATURE === 'true',
};Remove the flag and its dead branches once the feature is fully promoted.
Persistence keys (flowmind_snapshots, flowmind-clipboard, etc.) use a legacy prefix. Do not rename them without a migration path — renaming silently erases existing user browser data.
See ARCHITECTURE.md for a full breakdown of the store slices, hook hierarchy, node system, DSL, and export pipeline.