|
| 1 | +# Contributing to node-mssql |
| 2 | + |
| 3 | +Thanks for your interest in contributing to `node-mssql`! This project is community-maintained, and contributions of all kinds — bug reports, documentation, and code — are welcome. |
| 4 | + |
| 5 | +This guide covers how to report issues, set up a development environment, and submit changes that fit the project's conventions. |
| 6 | + |
| 7 | +## Code of Conduct |
| 8 | + |
| 9 | +This project and everyone participating in it is governed by our [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold it. Please report unacceptable behaviour as described in that document. |
| 10 | + |
| 11 | +## Reporting Issues |
| 12 | + |
| 13 | +### Security vulnerabilities |
| 14 | + |
| 15 | +**Do not** open public issues for security vulnerabilities. Please follow our [Security Policy](SECURITY.md) and report them privately instead. |
| 16 | + |
| 17 | +### Bugs |
| 18 | + |
| 19 | +Before opening a bug report, please search [existing issues](https://github.com/tediousjs/node-mssql/issues) to avoid duplicates. When you open a new issue, the issue template will ask for the information maintainers need to triage it effectively, including: |
| 20 | + |
| 21 | +- Expected and actual behaviour, with relevant SQL and schema where possible. |
| 22 | +- A minimal, reproducible example. |
| 23 | +- Software versions: Node.js, `node-mssql`, and SQL Server. |
| 24 | + |
| 25 | +### Feature requests |
| 26 | + |
| 27 | +Feature requests are welcome — please open an issue describing the use case and the problem you are trying to solve, rather than only a proposed implementation. |
| 28 | + |
| 29 | +## Development Setup |
| 30 | + |
| 31 | +1. Fork and clone the repository. |
| 32 | +2. Ensure you are running a supported Node.js version. The project requires **Node.js >= 18.19.0** (see the `engines` field in `package.json`). |
| 33 | +3. Install dependencies: |
| 34 | + |
| 35 | + ```bash |
| 36 | + npm install |
| 37 | + ``` |
| 38 | + |
| 39 | +### Running the tests |
| 40 | + |
| 41 | +| Command | Description | |
| 42 | +| ------- | ----------- | |
| 43 | +| `npm test` | Runs the linter (StandardJS) followed by the unit tests. This is the baseline check that must pass. | |
| 44 | +| `npm run lint` | Runs StandardJS only. | |
| 45 | +| `npm run test-unit` | Runs the unit tests only. No database required. | |
| 46 | +| `npm run test-tedious` | Runs the integration tests against a live SQL Server using the `tedious` driver. | |
| 47 | +| `npm run test-msnodesqlv8` | Runs the integration tests using the `msnodesqlv8` driver. | |
| 48 | +| `npm run test-cli` | Runs the CLI tool tests. | |
| 49 | + |
| 50 | +To run a single unit test by name: |
| 51 | + |
| 52 | +```bash |
| 53 | +npx mocha --exit -t 15000 --grep "test name" test/common/unit.js |
| 54 | +``` |
| 55 | + |
| 56 | +### Integration tests |
| 57 | + |
| 58 | +The integration tests require a running SQL Server instance configured in `test/.mssql.json` (see `.devcontainer/.mssql.json` for the expected shape). The included [dev container](https://containers.dev/) sets up both Node.js and SQL Server via Docker Compose, which is the easiest way to run the full suite locally. |
| 59 | + |
| 60 | +Unit tests (`npm run test-unit`) do **not** require a database, so you can develop and validate most changes without a SQL Server instance. |
| 61 | + |
| 62 | +## Coding Standards |
| 63 | + |
| 64 | +- **Style:** The project uses [StandardJS](https://standardjs.com/) — no semicolons, 2-space indentation, single quotes. There is no config file or override; run `npm run lint` to check your work, and `npx standard --fix` to auto-fix many issues. |
| 65 | +- **Driver-agnostic design:** Shared, public API lives in `lib/base/`; driver-specific implementations live in `lib/tedious/` and `lib/msnodesqlv8/` and override private methods prefixed with an underscore (e.g. `_poolCreate`, `_executeQuery`). |
| 66 | +- **Dual API:** Async methods should support both Promises and callbacks. |
| 67 | +- **Tests:** Add or update tests for any behavioural change. Unit tests go in `test/common/unit.js`; integration tests are added to the shared factory in `test/common/tests.js` so they run against every driver. |
| 68 | + |
| 69 | +## Commit Messages |
| 70 | + |
| 71 | +Commit messages **must** follow the [Conventional Commits](https://www.conventionalcommits.org/) specification. This is enforced by commitlint, and [semantic-release](https://semantic-release.gitbook.io/) uses these messages to automate versioning and changelog generation — so using the correct type matters. |
| 72 | + |
| 73 | +| Type | When to use it | Release impact | |
| 74 | +| ---- | -------------- | -------------- | |
| 75 | +| `fix` | Bug fixes or behavioural corrections that don't change the public interface | **patch** | |
| 76 | +| `feat` | New backwards-compatible functionality | **minor** | |
| 77 | +| `feat!` (or any type with `!`, or a `BREAKING CHANGE:` footer) | Changes that require consumers to update their code | **major** | |
| 78 | +| `chore` | Dependency updates, tooling, housekeeping | none | |
| 79 | +| `ci` | CI pipeline or workflow configuration changes | none | |
| 80 | +| `docs` | Documentation-only changes | none | |
| 81 | +| `style` | Formatting or stylistic changes that don't affect behaviour | none | |
| 82 | +| `refactor` | Code changes that neither fix a bug nor add a feature | none | |
| 83 | +| `test` | Changes that only touch tests | none | |
| 84 | + |
| 85 | +Only `fix` and `feat` trigger a release. If a change needs to be released but doesn't neatly fit either, choose whichever is most appropriate to ensure a release is created. |
| 86 | + |
| 87 | +## Pull Requests |
| 88 | + |
| 89 | +- **Branch from an up-to-date `master`.** All changes go through a pull request — there are no direct commits to `master`. |
| 90 | +- **Keep commits atomic.** Each commit should be a self-contained, deployable change with linting, commitlint, and tests passing. Don't mix unrelated changes (e.g. a bug fix and a documentation tweak) in one commit. |
| 91 | +- **Keep your branch current by rebasing** onto `master` rather than merging `master` into your branch. |
| 92 | +- **PRs are merged with a merge commit** (no squash or rebase merge), so each commit in your PR is preserved in history. Please keep that history clean. |
| 93 | +- Fill out the pull request template, link any related issues, and update the changelog where applicable. |
| 94 | +- Make sure `npm test` passes before requesting review. |
| 95 | + |
| 96 | +For additional background, see the [Contributing page on the project wiki](https://github.com/tediousjs/node-mssql/wiki/Contributing). |
| 97 | + |
| 98 | +Thanks again for contributing! |
0 commit comments