# Contributing

Thanks for your interest in improving **node-red-contrib-modbus-modpackqt**.
This document explains how to report issues, suggest features, and submit code
changes.

## Reporting bugs

Before opening an issue:

1. Make sure you're on the **latest version** (`npm outdated` in `~/.node-red`).
2. Check if the issue is reproducible against the [bundled example flow](./examples/basic-flow.json).
3. Re-read [`DISCLAIMER.md`](./DISCLAIMER.md) — some "bugs" are actually
   undocumented behaviour or known limitations.

When you file an issue, please include:

- Palette version (from `package.json` or the Node-RED palette manager)
- Node.js version (`node --version`)
- Node-RED version
- Operating system
- The smallest possible Node-RED flow that reproduces the issue (export from
  Menu → Export → JSON)
- Console / debug output, with timestamps if possible
- A `modpackqt-traffic` node's output if the issue involves Modbus operations

Where to file:

- **Bugs and feature requests:** <https://modpackqt.com/contact> (or the
  package's GitHub repo when listed in `package.json`)
- **Security issues:** see [`SECURITY.md`](./SECURITY.md) — do not file
  publicly

## Suggesting features

We're happy to consider new ideas. Before opening a request:

- Describe the use case in plain language ("I want to read a 64-bit timestamp
  from a Schneider device") — not the implementation ("add a new
  decode-timestamp node").
- Explain why the existing nodes can't already solve it (often they can —
  composing `decode-uint32 BE_SWAP` + a `function` node solves a lot).

## Submitting code changes

1. **Open an issue first** for non-trivial changes so we can agree on the
   approach before you spend time on a PR.
2. **Keep changes small and focused** — one feature or fix per PR.
3. **Preserve backward compatibility.** This package is shipped to many
   production deployments; breaking changes require a major version bump and
   a clear migration path.
4. **Test against the example flow.** At minimum, importing `basic-flow.json`
   and running each section should still work.
5. **Update `CHANGELOG.md`** under "Unreleased".
6. **Update the README** if you add or change a node's behaviour.
7. **Bump versions only on release.** Maintainers handle the version bump
   when publishing.

## Code style

- Vanilla Node.js — no TypeScript, no transpilation, no build step.
- 2-space indent.
- Prefer small, well-named helper functions over clever one-liners.
- Wrap risky operations in `try/finally` and emit errors via `node.error()`
  rather than throwing into Node-RED's runtime.

## Licence

By submitting a PR you agree to licence your contribution under the project's
[MIT licence](./LICENSE).