feat!: show input from a new line#4102
Conversation
This will be less confusing to read, and also easier to test and copy/paste..
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
|
Thanks! I understand that this might be a bit confusing for first time users but this is not a common issue we get. So I would rather close this. It doesn't justify a breaking change. |
|
@escapedcat this was confusing for 16k users who starred this and will be confusing for a 100k+ more who just don't know what GitHub is. If the confusion if just 5 minutes, it is still worth the output breaking change for me. For integration with editors and stuff, I guess |
|
Thanks for your feedback. Might be good to open up an issue for this to discuss this further and get some feedback from others. Try searching if we maybe have similiar issues already. Thanks! |
|
@escapedcat why this issue is not suitable to discuss it? |
Hm, no, it is, but I would prefer you open up an official issue for this to get some feedback/input from other users. |
|
@escapedcat created #4112 |
There was a problem hiding this comment.
Pull request overview
Updates @commitlint/format’s displayed “input” so the commit message starts on a new line, improving readability and copy/paste ergonomics (notably for multi-line messages with URLs as in #4101).
Changes:
- Change formatted output from
⧗ input: <message>to a two-line banner⧗ --- input ---followed by the raw commit message on the next line. - Update the corresponding
@commitlint/formatunit test expectation for verbose output.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
@commitlint/format/src/format.ts |
Adjusts the formatted “input” header to include a banner + newline before the commit message. |
@commitlint/format/src/format.test.ts |
Updates the verbose-mode snapshot/expectation to match the new banner output. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
|
|
||
| return options.verbose || hasProblems | ||
| ? [`${decoration} input: ${decoratedInput}`] | ||
| ? [`${decoration} --- input ---\n${decoratedInput}`] |
| '⧗ --- input ---\nfeat(cli): this is a valid header\n\nThis is a valid body\n\nSigned-off-by: tester\n✔ found 0 problems, 0 warnings' | ||
| ); | ||
| }); | ||
|
|
|
@Copilot can you change |
Hey, not sure why copilot is not acting on these requests, maybe it needs maintainer to comment, not just a contributor? Anyway, if you could address the feedback from it? There are two comments which include easy suggestions that can just be applied by pressing a button. |
|
If this is being continued please make this optional with default true so people can turn it off if needed. Maybe in the future we can deprecate the option and make it default. Let's see. |
|
Eventually will be done in here: #4727 |
|
@escapedcat I turned "Allow edits by maintainers" on, so that you can reopen and edit this PR if needed. Chances that I am going back to restore dev environment and figure out how to make it optional are minimal. |
This will be less confusing to read, and also easier to test and copy/paste (for example for #4101).
This error log is confusing for people not familiar with
commitlint.This one should be more clear.
Or maybe even this one.
Motivation and Context
Error output should not mess up original commit message, because it is hard to understand what is wrong.
Usage examples
How Has This Been Tested?
Types of changes
Checklist: