package-comments complains for no reason

[marcelloh]

Describe the bug
I have a package comment (in a doc.go), but when I have a comment in another file inside the same package, it complains that it isn't a good one.

To Reproduce
make one valid package comment in a package
My doc.go example

/*
Package migrations holds database migrations and seeders.
*/
package migrations

Now add in another file a comment not being a package comment

I use revive version 1.3.4

revive -formatter friendly -exclude ./vendor/... ./...

no toml

Expected behavior
N0 complains, because there is a valid package comment in the package

Logs

Desktop (please complete the following information):

• OS: Mac Os 14 (Sonoma)
• go version go1.21.3 darwin/arm64

Additional context

[chavacava]

Hi @marcelloh, thanks for reporting this issue.
Could you please provide:

1. An example of add in another file a comment not being a package comment
2. The actual failure generated by revive
   ?

[marcelloh]

Example (what you can put on top of the other file in the same package)

//nolint:dupl,revive // looks the same but isn't

package migrations

and message is:

─── revive version 1.3.4
  ⚠  https://revive.run/r#package-comments  package comment should be of the form "Package migrations ..."  
  services/migrations/languageMigration.go:1:1

[chavacava]

Thanks.
IMO the behavior of the rule is OK. The comment attached to the package declaration does not respect the conventions enforced by the rule.
Must the rule warn in this case even if there is another file in the package where the convention is respected? I think it must.
What do you think?

[marcelloh]

There should be a valid package comment present in the package. In my example, there is
There is only one valid package comment in all the files in the package. Not every file needs to have the same comment.
This means that revive should not complain if it find extra comments that don't fit the valid comment.

The fact i'm running golangci-lint (with inside revive) and after that some separate linters, also with revive), gives this effect.
Perhaps if I change the first line :

//revive:disable
//nolint:dupl,revive // looks the same but isn't
//revive:enable
package migrations

this probably works but looks really ugly