Add support for inherits and class references

[bodgit]

Now detects violations such as:

class foo inherits ::bar {}

and

Class['::foo'] -> Class['::bar']

Fixes #20

[alexjfisher]

Good stuff. I'd actually written an implementation a few days back, but hadn't gotten around to committing it yet! I prefer yours though. :)

[alexjfisher]

We should probably use a different message here?
class included by absolute name isn't accurate.

[alexjfisher]

Looking good I think. Could you update the README?

[alexjfisher]

I can't decide whether the next release should be 3.0.0 or not. I suppose this is 'breaking' in so much that lots of manifests that passed before, won't now. 'inherits' could be argued to be a way of including a class, but Class references aren't and checking them doesn't fall under the current gem's description (A puppet-lint plugin to check that classes are included by their absolute name.), which needs updating anyway.

@bodgit Could you update the gemspec with a new summary and description as well as updating the README?

[ekohl]

I think this will work, but it's also valid to write require => Class['::foo', '::bar'] and it should detect both. Another example would be require => [Class['::foo'], Class['::bar']]. Could you include tests for that as well?

[bodgit]

I think this will work, but it's also valid to write require => Class['::foo', '::bar'] and it should detect both. Another example would be require => [Class['::foo'], Class['::bar']]. Could you include tests for that as well?

I'd forgotten about the first syntax, thankfully the code still works with some extra tests added.

[ekohl]

Thanks for adding those tests. If you address #23 (comment) I think this should be good to merge.

[alexjfisher]

I guess bare words and interpolated strings are also valid puppet? Ideally the plugin would also detect (and fix)

Class[::foo] -> Class["::foo::install::${osfamily}"]

Not a blocker for me though.

[bodgit]

Is it worth making the class references check separate within this gem?

[alexjfisher]

Is it worth making the class references check separate within this gem?

Possibly. That would let users turn it off if they didn't like it. Or we could default it to off for a release and then turn it on in the next major release.

[alexjfisher]

But like I said in #23 (comment), getting it perfect is not a blocker. I think the new check is already going to be covering 90%+ of uses.

For the existing checking of how classes are included, I can keep coming up with obscure corner cases too, but life isn't long enough to try and catch them all.

eg (I've seen this style in the last week, complete with random trailing comma and all those single quotes)

include '::foo::bar', '::foo:foobar', 'foo',

or as an actual array (instead of the comma separated string above)

include [::foo::bar,'foo','::foo::foobar']

I think even the following is valid and would compile just fine...

[
  '::foo::bar',
  'foo',
  ::foo::foobar,
].include

[bodgit]

I've split out the class reference check, updated the gemspec and README, and added support for bare class names as that was an easy addition. Anything else?

[alexjfisher]

@bodgit Superb contribution. Thank you!