Use when a source code change needs a changelog entry, or before committing and pushing any bug fix, feature, or behavior change to source code - detecting when entries are required, categorizing changes correctly (added/changed/fixed/deprecated/removed/security), writing user-facing titles, and creating the JSON entry in .changelogs/
Any PR that changes source code needs a changelog entry. This includes bug fixes, new features, behavior changes, deprecations, and security fixes.
Not required for:
Add [skip changelog] in the PR description to explicitly skip.
Create a file at .changelogs/{issue-or-pr-number}.json:
{
"issuesOrigin": "public",
"title": "User-facing description of what changed.",
"type": "fixed",
"issueOrPR": 12345,
"breaking": false,
"framework": "none"
}
| Type | When to use | Title example |
|---|---|---|
added | A wholly new feature or capability | "Added pagination plugin for large datasets." |
changed | Enhancement or modification to existing behavior | "Improved column resize performance with CSS scale transforms." |
fixed | A bug fix | "Fixed filters not updating after manual column move." |
deprecated | Feature scheduled for removal in the next major | "Deprecated moment-based date formatting in favor of native Intl." |
removed | Feature already removed in this release | "Removed legacy row grouping plugin." |
security | Vulnerability or XSS fix | "Fixed XSS vulnerability in custom HTML cell renderer." |
"breaking": true) appear first in the generated changelog. Make the title clearly describe what breaks and what to do instead.| Value | When to use |
|---|---|
"none" | Default. Change affects the core handsontable package. |
"react" | Change is specific to @handsontable/react-wrapper. |
"angular" | Change is specific to @handsontable/angular-wrapper. |
"vue" | Change is specific to @handsontable/vue3. |
For interactive creation, run:
node bin/changelog entry
This walks you through each field and writes the JSON file for you. You can also create the file manually -- the format is simple enough.
Create one changelog entry per PR, even if the PR fixes multiple issues. The title should describe the overall change, not list individual issues.
type from the table above.title ending with a period.breaking to true only if the change breaks existing behavior.framework to match the affected package, or "none" for core.