|
| 1 | +# Contributing to Contentstack Utils JavaScript |
| 2 | + |
| 3 | +Thank you for your interest in contributing to Contentstack Utils JavaScript. This document provides guidelines and instructions for contributing. |
| 4 | + |
| 5 | +## Pull Request Target Branch |
| 6 | + |
| 7 | +**All pull requests must be raised against the `development` branch.** |
| 8 | + |
| 9 | +Do not open PRs against `master` or `staging`. Create your feature or fix branch from `development`, and open your PR to merge into `development`. Maintainers will handle promotion to other branches after review. |
| 10 | + |
| 11 | +## Getting Started |
| 12 | + |
| 13 | +### Prerequisites |
| 14 | + |
| 15 | +- **Node.js** 10 or later |
| 16 | +- **npm** (comes with Node.js) |
| 17 | +- **Git** |
| 18 | + |
| 19 | +### Development Setup |
| 20 | + |
| 21 | +1. **Fork the repository** on GitHub and clone your fork locally: |
| 22 | + |
| 23 | + ```bash |
| 24 | + git clone https://github.com/YOUR_USERNAME/contentstack-utils-javascript.git |
| 25 | + cd contentstack-utils-javascript |
| 26 | + ``` |
| 27 | + |
| 28 | +2. **Add the upstream remote** (optional, for syncing with the main repo): |
| 29 | + |
| 30 | + ```bash |
| 31 | + git remote add upstream https://github.com/contentstack/contentstack-utils-javascript.git |
| 32 | + ``` |
| 33 | + |
| 34 | +3. **Create a branch from `development`** for your work: |
| 35 | + |
| 36 | + ```bash |
| 37 | + git fetch upstream |
| 38 | + git checkout development |
| 39 | + git pull upstream development |
| 40 | + git checkout -b your-feature-or-fix-name |
| 41 | + ``` |
| 42 | + |
| 43 | +4. **Install dependencies:** |
| 44 | + |
| 45 | + ```bash |
| 46 | + npm install |
| 47 | + ``` |
| 48 | + |
| 49 | +5. **Build the project:** |
| 50 | + |
| 51 | + ```bash |
| 52 | + npm run build |
| 53 | + ``` |
| 54 | + |
| 55 | +## Development Workflow |
| 56 | + |
| 57 | +### Running Tests |
| 58 | + |
| 59 | +- Run the full test suite: `npm test` |
| 60 | +- Run tests in watch mode (for development): `npm run test:debug` |
| 61 | + |
| 62 | +All tests must pass before submitting a PR. New features and bug fixes should include or update tests as appropriate. |
| 63 | + |
| 64 | +### Code Style |
| 65 | + |
| 66 | +- **ESLint:** The project uses ESLint. Fix auto-fixable issues with your editor or by running the linter. |
| 67 | +- **Prettier:** Code is formatted with Prettier. Use `npm run format` to format `src/**/*.ts`. |
| 68 | + |
| 69 | +Ensure your code adheres to the existing style so that CI and pre-commit checks pass. |
| 70 | + |
| 71 | +### Commit Messages |
| 72 | + |
| 73 | +This project uses [Conventional Commits](https://www.conventionalcommits.org/) enforced by Commitlint. |
| 74 | + |
| 75 | +- Use a **type** and a **short subject** (e.g. `feat: add jsonToHTML option`, `fix: handle empty nodes`). |
| 76 | +- Allowed types include: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`, `sample`. |
| 77 | +- Subject should be lowercase, imperative, and not end with a period. |
| 78 | +- Add a blank line and a longer body when the change needs more explanation. |
| 79 | + |
| 80 | +Husky runs a commit-msg hook to validate commit messages. Invalid messages will be rejected. |
| 81 | + |
| 82 | +### Pre-commit Hooks |
| 83 | + |
| 84 | +Husky is used for Git hooks. Before each commit, the pre-commit hook runs. Ensure your working tree is clean and that tests and lint pass locally to avoid failed commits. |
| 85 | + |
| 86 | +## Submitting Changes |
| 87 | + |
| 88 | +1. **Keep your branch up to date** with `development`: |
| 89 | + |
| 90 | + ```bash |
| 91 | + git fetch upstream |
| 92 | + git rebase upstream/development |
| 93 | + ``` |
| 94 | + |
| 95 | +2. **Open a Pull Request** against the **`development`** branch (not `master` or `staging`). |
| 96 | + |
| 97 | +3. **Fill out the PR template** (if one exists) and provide: |
| 98 | + - A clear title and description of the change |
| 99 | + - Link to any related issue |
| 100 | + - Summary of testing done |
| 101 | + |
| 102 | +4. **Address review feedback** promptly. Maintainers may request changes before merging. |
| 103 | + |
| 104 | +5. **Do not force-push** after review has started unless the maintainer asks you to; use new commits for updates when possible so review history is preserved. |
| 105 | + |
| 106 | +## Reporting Issues |
| 107 | + |
| 108 | +- Use the GitHub issue tracker for bugs and feature requests. |
| 109 | +- Search existing issues first to avoid duplicates. |
| 110 | +- Include steps to reproduce for bugs, and your environment (Node version, OS). |
| 111 | +- For security issues, see [SECURITY.md](SECURITY.md). |
| 112 | + |
| 113 | +## Additional Resources |
| 114 | + |
| 115 | +- [README](README.md) – Project overview and usage |
| 116 | +- [CHANGELOG](CHANGELOG.md) – Version history and changes |
| 117 | +- [SECURITY](SECURITY.md) – Security and vulnerability reporting |
| 118 | +- [CODEOWNERS](CODEOWNERS) – Code ownership and review expectations |
| 119 | + |
| 120 | +Thank you for contributing. |
0 commit comments