Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
104 lines (70 loc) · 4.39 KB

CONTRIBUTING.md

File metadata and controls

104 lines (70 loc) · 4.39 KB

Contributing to markdown-it-anchor-sections

Contributions of all kinds are welcome: bug fixes, new features, documentation improvements, and test coverage. If you're unsure whether your idea fits the project, open an issue first and we'll figure it out together.

Before you start

  1. Search existing issues before opening a new one — your bug or idea may already be in progress.
  2. Open an issue to discuss non-trivial changes before writing code. This saves everyone time and avoids PRs that can't be merged.
  3. Fork the repository and clone your fork locally: 
    git clone https://github.com/<your-username>/markdown-it-anchor-sections.git
cd markdown-it-anchor-sections
yarn install

Development workflow

Branching

Create a branch from main that describes your change:

git checkout -b fix/empty-value-handling
git checkout -b feat/glob-pattern-support

Running tests

This project uses AVA for its test suite and c8 for coverage:

yarn test           # run the full test suite
yarn coverage       # run tests with coverage report

All new functionality must be accompanied by tests. Look through the existing tests in test.js to get a feel for the conventions. AVA runs tests concurrently by default — make sure any tests that touch the filesystem use isolated temporary directories and clean up after themselves.

Linting and formatting

Code style is enforced by ESLint and Prettier. Both run automatically on staged files before every commit via lint-staged. You can also run them manually:

yarn eslint .
yarn prettier --check .

If Prettier flags a file, run yarn prettier --write . to fix it automatically.

Commit messages

This project uses Conventional Commits. Commit messages are linted automatically on every commit — a malformed message will be rejected. The format is:

<type>(<optional scope>): <short description>

[optional body]

[optional footer(s)]

Common types:

Type When to use
feat A new feature (triggers a minor release)
fix A bug fix (triggers a patch release)
docs Documentation changes only
test Adding or updating tests
refactor Code restructuring without behaviour change
chore Tooling, config, dependency updates

A BREAKING CHANGE: footer or a ! after the type (e.g. feat!:) triggers a major release.

Pull requests

  • Keep PRs focused — one logical change per PR
  • Update or add tests for every changed behaviour
  • The PR title should follow the same Conventional Commits format as your commit messages, since it becomes the squash commit message on merge
  • Fill out the PR description — explain what changed and why, not just what the diff shows

Project structure

markdown-it-anchor-sections/
├── index.js # core logic (copyEnv, parseLine, parseEnvFile, …)
├── test.js # test suite
├── eslint.config.js
└── .github/
└── workflows/ # CI and release automation

Type annotations are written as JSDoc rather than TypeScript. jsconfig.json enables strict checking in VS Code — please keep annotations up to date for any functions you add or modify.

Release process

Releases are fully automated via semantic-release — no manual versioning or changelog editing required. Merging to main triggers the release workflow, which analyses commit messages since the last release, bumps the version, generates the changelog entry, tags the commit, and publishes to npm.

You do not need to update package.json version or CHANGELOG.md by hand.

Code of Conduct

This project follows the Contributor Covenant Code of Conduct. By participating you agree to uphold a welcoming and respectful environment for everyone. Harassment, discrimination, or exclusionary behaviour of any kind will not be tolerated.

If you experience or witness unacceptable behaviour, please report it by opening a private issue or emailing castastrophe@users.noreply.github.com. All reports will be handled with discretion.