User Guide has incorrect example code comments in "unicode-bom" rule page

[BrandonYeager]

The example code in the page for the unicode-bom rule has incorrect comments (https://eslint.org/docs/rules/unicode-bom#require-or-disallow-the-unicode-byte-order-mark-bom-unicode-bom).

The "always" examples should say /*eslint unicode-bom: ["error", "always"]*/
The "never" examples should say /*eslint unicode-bom: "error"*/

---

See screenshot for a clearer explanation...

[platinumazure]

I'm okay with fixing the first two examples, but I'm not sure we should change the latter 2 examples. I like being explicit with what option is being discussed. If we want to add another section showing the default behavior, I'd be okay with that.

I don't feel strongly about this, though.

[BrandonYeager]

I submitted a PR based on my original proposed change. I agree that being explicit would be better based on the above comment.

I haven't contributed to many open source projects, so I have a question... Would it be preferable to modify my existing commit on my branch or adding a second commit modifying the code I currently have? (edit: it has already been reviewed)

[platinumazure]

Hi @BrandonYeager, you can push a second commit to the branch-- we'll squash when we merge. This allows us to keep track of the full history even as new commits are added. Thanks!

[BrandonYeager]

@platinumazure Thanks for the information! I'm looking forward to contributing more in the future!

One more question... when modifying a PR, do you still follow the code conventions for every commit message with the Tag and issue number? Or do you typically squash to the first commit message so it doesn't matter after the first message?

[platinumazure]

@BrandonYeager Our commit message check looks at the PR title if there are 2 or more commits in the PR, because that's what the suggested commit message is when we squash/merge. (If there is 1 commit, the first commit's message is used instead, and our commit message check looks at the commit message for that reason.) So you can put whatever you want in the later commit messages.

[BrandonYeager]

@platinumazure Thank you for the information and the rapid responses to my questions! You guys are doing an awesome job!