feature request: check for version numbers

[rayjlinden]

This is a cool linter. However, the more common problem we have is using an old version of a go package that really needs to be updated to a later version due to a security issue or bug found in older version. It would be cool if one could specify min version allowed for particular packages, etc.

[Will Dixon]

Since import paths don't have the actual version in them, this would require parsing the go.mod or go.sum file. The true issue with doing so is that a go module is not a go package. Meaning my module could be github.com/OpenPeeDeeP/depguard but the package I am importing is github.com/OpenPeeDeeP/depguard/subpackage. Since I am given the latter when parsing through the files I have no quick way of determining that.

But I do think this could be a different linter. This linter would not need any build context at all and would require go modules. But basically it checks from a map and version against the go.mod and go.sum files. Also, until go1.13, you couldn't use the timestamp on the version of a module that was not ported yet as it was not verified.

TL;DR; I don't think is a depguard feature as it would add too much overhead and goes against the grain of what it currently does under the hood. But I do think you are on to something for a different linter all together.

[Will Dixon]

I want to keep this open cause I don't want to forget about this idea though.

[Will Dixon]

@rayjlinden with #13 and #14, I may be revisiting how the configuration is structured. I may be able to implement this in this linter. I may try and do some research while working on that configuration and see what a syntax for versioning would look like? (npm and how it does version in the package.json comes to mind).

[rayjlinden]

BTW - I did end up creating this little bash script which if I run in a repo will tell me which modules have updates available:
(Some updates one may not want forced to be updated - but some you do. That is the functionality I still need...)

#!/bin/bash
# Author: [e-mail]

result=$(go list -u -m -json all)
if [ x"$result"x = x""x ] ; then
	echo "no dependancy information found"
	exit 1
fi

count=$(echo $result | jq -r '. | select(.Update) | select(.Indirect == null) | length' | wc -l)
if [ $count -eq 0 ] ; then
	echo "all dependancies up to date"
	exit 0
fi
echo "There are $count dependancies out of date:"
echo $result | jq -r '. | select(.Update) | select(.Indirect == null) | .Path + "@" + .Version + " => " + .Path + "@" + .Update.Version'

[Lucas Bremgartner]

I use this linter to detect, when an old major version of a package is used. The major-version in this case is in the import path due to how go modules work with major versions.

This can be done with the following glob: {github.com/gobuffalo/plush}

My use case is:

I have to make sure, that I use github.com/gobuffalo/plush/v4 everywhere in the code, but sometimes goimports automatically creates an import for github.com/gobuffalo/plush.
So with the above configuration, I can use depguard to detect these imports.

Note, that in this case the glob is necessary, because the prefix match will not work as both imports share the same prefix.

[Will Dixon]

Specifically looking at the prefix causing the issue. Not specific versions in the mod file. But will keep in mind for v2 milestone.

[Will Dixon]

Added ability for exact matches in prefix listings in v2 branch. so in your above example, adding github.com/gobuffalo/plush$ to your deny list will match github.com/gobuffalo/plush flagging it but won't match github.com/gobuffalo/plush/v4 which would allow it.