Typos claims a typo in a version number in a go.mod file

[neilschark]

Please complete the following tasks

• I have searched the open and rejected issues

Example data

github.com/dprotaso/go-yit v0.0.0-20220510233725-9ba8df137936 // indirect

Incorrect correction

error: ba should be by, be

Description of data format

A normal go.mod file for dependency management in go.

Example:

module test/test

go 1.24

require (
	github.com/dprotaso/go-yit v0.0.0-20220510233725-9ba8df137936
)

Justification

A go.mod file is always used in golang.

I will just exclude the file from being checked, as there is not much use to it anyways.

Notes

Output from our CI

$ typos
error: `ba` should be `by`, `be`
  --> ./go.mod:32:52
   |
32 |  github.com/dprotaso/go-yit v0.0.0-20220510233725-9ba8df137936 // indirect
   |                                                    ^^
   |

[epage]

I'm assuming the hash 9ba8df137936 is below our threshold for being ignored

Our main issue for things like that are

• Hashes/encodings below the heuristic limit are treated as typos #415
• Heuristics for "random" values to help with base-encoded typo false positives #484

A workaround is defining a extend-ignore-re to match that line.

The question from there is if we should have special casing to detect the go case.

Note that for lockfiles

typos/crates/typos-cli/src/default_types.rs

Lines 163 to 170 in 9c80e63

	("lock", &[
	"*.lock",
	"package-lock.json", "pnpm-lock.yaml",
	"composer.lock", "*.terraform.lock.hcl",
	"requirements.txt",
	"go.sum",
	"go.work.sum",
	]),

we exclude them from checking

typos/crates/typos-cli/src/file_type_specifics.rs

Line 7 in 9c80e63

pub(crate) const NO_CHECK_TYPES: &[&str] = &["cert", "lock"];

Its looking like go.mod isn't quite a lockfile but isn't quite a human edited file.

[epage]

Huh, we had #683 which was fixed in #684 which doesn't quite look correct. It just dropped go.mod from being considered a go file type but it didn't add it to any exclusion lists.

[ccoVeille]

For record, the following files have a similar format

• go.mod
• go.sum
• go.work
• go.work.sum

If you want to work on that @epage

[epage]

Do you have a primary source I can refer back to on that?

[ccoVeille]

Do you have a primary source I can refer back to on that?

@epage

https://go.dev/ref/mod#go-mod-file
https://go.dev/ref/mod#go-sum-files
https://go.dev/ref/mod#go-work-file (this one describes go.work and go.work.sum

https://go.dev/doc/modules/gomod-ref

But but I would sum it up this way

Only comments should be considered:

• // a comment
• /* multiline comment */

Everything else in these files must be ignored.

• go.mod
• go.sum
• go.work
• go.work.sum

[ccoVeille]

Here are a GitHub search if you are looking for examples

https://github.com/search?q=path%3A%2F%5Ego%5C.%28mod%7Cwork%7Csum%7Cwork%5C.sum%29%24%2F+%2F%5E%5Cs*%5C%2F%5C%2F%2F&type=code

[epage]

Reading those, it sounds like go.mod and go.work are related and go.sum and go.work.sum are related.

It also appears that the .sum files are more like lockfiles while go.mod and go.work are packaging specifications. However, go.mod is oriented around human readability and focused on machine writeability (go.works docs don't mention this).

You and the docs mention comments. Do the commands that manipulate go.mod preserve user comments?

[ccoVeille]

Reading those, it sounds like go.mod and go.work are related and go.sum and go.work.sum are related.

Exactly

It also appears that the .sum files are more like lockfiles while go.mod and go.work are packaging specifications. However, go.mod is oriented around human readability and focused on machine writeability (go.works docs don't mention this).

Exactly.

But based on your comment, I think there is no user comment in go.sum and go.work.sum

Confirmed

Only go.mod and go.work should be considered

https://github.com/search?q=path%3A%2F%5C%2Fgo.%28mod%7Cwork%29%24%2F+%2F%5C%2F%5C%2F+%5B%5Ei%5D%5B%5En%5D%2F&type=code

Please note // indirect is added when the dependency is indirect, you don't have to ignore it as it's a valid word

You and the docs mention comments. Do the commands that manipulate go.mod preserve user comments?

It does, unless you remove a dependency via go mod, so it removes the line and it's comment. But this is expected

[epage]

So it sounds like #684 should be reverted and we should classify go.mod and go.work with *.go and this just becomes a hash detection issue.