Skip to content

Conversation

@szokeasaurusrex
Copy link
Member

Implement the ability to override changelog entries using a "Changelog Entry" section in the PR description.

This allows PR authors to provide more detailed, user-facing release notes directly within the PR body, improving clarity and flexibility for changelog generation. If no such section is present, the PR title is used as the changelog entry as before.


Open in Cursor Open in Web

@cursor
Copy link

cursor bot commented Dec 4, 2025

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
Learn more about Cursor Agents

@szokeasaurusrex
Copy link
Member Author

@cursor update the PR title to actually describe the changes

@cursor
Copy link

cursor bot commented Dec 4, 2025

Create PR

Based on the implemented changes, here's a better PR title that accurately describes what this PR does:

Suggested PR Title:

feat: Allow changelog entry to be overridden by PR description section

Or alternatively:

feat: Support custom changelog entries via "Changelog Entry" section in PR descriptions

Both options clearly convey that this PR:

  1. Adds a new feature (using the feat: prefix following conventional commits)
  2. Allows PR authors to override the default changelog entry
  3. Uses a specific section in the PR description to achieve this

The first option is more concise while the second provides slightly more detail about the mechanism. Either would be a significant improvement over "Respond to github message"!

Would you like me to suggest any other variations, or would one of these work for you?


Open in Cursor Open in Web

Learn more about Cursor Agents

@szokeasaurusrex szokeasaurusrex changed the title Respond to github message feat: Allow changelog entry to be overridden by PR description section Dec 4, 2025
@szokeasaurusrex
Copy link
Member Author

@cursor fix the lints

@cursor
Copy link

cursor bot commented Dec 4, 2025

Create PR

Perfect! All linter warnings have been fixed. ✅

What I Fixed

Replaced all 26 instances of non-null assertion operator (!) in the test file with proper type guards using if (result) checks. This is the safer TypeScript pattern that the linter prefers.

Before:

expect(result![0].text).toBe('...');

After:

expect(result).not.toBeNull();
if (result) {
  expect(result[0].text).toBe('...');
}

Verification

  • Linter: Clean - no errors or warnings
  • Tests: All 449 tests passing
  • Type safety: Improved with proper null checks

The code is now ready for review with no linting issues!


Open in Cursor Open in Web

Learn more about Cursor Agents

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants