Packages needing specs

[Arcanemagus]

Every package should have specs written for it to verify it is working properly, and that things don't break with dependency updates, not to mention the fact that this will cut down the greenkeeper PR's by far as it will know whether a dependency actually needs work when it updates, instead of having to submit a PR for every update 😉

For an extremely basic "we know it's somewhat working" example of specs, check out linter-erb, for a more complete example that checks far more of the actual functionality of the linter, try checking out linter-eslint.

If you have any questions or want some help speak up and we'll do what we can to help out!

Linter plugins needing specs:

• linter-erlc
• linter-jscs
• linter-elixirc
• linter-swagger
• linter-docker
• linter-puppet-lint
• linter-rubocop
• linter-ruby
• linter-cpplint
• linter-javac
• linter-pep257
• linter-golinter
• linter-haml
• linter-reek
• linter-jshint
• linter-foodcritic
• linter-harbour
• linter-clojure
• linter-gjslint
• linter-htmlhint
• linter-jsonlint
• linter-lua
• linter-shellcheck
• linter-pycodestyle
• linter-flint
• linter-pylama
• linter-stylint
• linter-lsc
• linter-coffeelint
• linter-tslint
• linter-tidy
• linter-pyflakes
• linter-hlint
• linter-moonscript
• linter-dartanalyzer
• linter-rst
• linter-slim
• linter-roodi
• linter-swiftc
• linter-swiftlint
• linter-phplint
• linter-gotype
• linter-govet
• linter-bailey
• linter-flexpmd
• linter-spell-word-list

Package has since been deleted, archived, implemented elsewhere, or deprecated in some other way:

• linter-jsl
• linter-oclitnt
• linter-codscriptizer
• linter-kibit
• linter-mcs
• ansible-lint
• linter-recess

[AsaAyers]

Why do you think every dependency needs to be updated on every package as soon as an update is available? There's a common phrase "If it aint broke, don't fix it".

Security updates are very important, but do those even apply to any of the packages you're talking about? So I guess you might like to get bug fixes, but do you really care about fixes for bugs your users aren't encountering? Feature updates don't matter unless you're writing new code to take advantage of the feature. I just can't find a solid reason why these kinds of packages have to have updates as soon as they become available.

[AsaAyers]

The reason you're talking about needing specs is that you recognize that the updates introduce risk, but I just can't find any reward that balances it.

[steelbrain]

If it aint broke, don't fix it

@AsaAyers That is exactly what we intend to do. If we add specs in every package, greenkeeper would know which packages broke with specs and only PR to them and ignore the other ones that have passing specs on the newly released version.

[AsaAyers]

Maybe I just don't get what greenkeeper does. Does it just check the range of what your package says it works with to verify it really works in that range?

[steelbrain]

@AsaAyers Yep! It checks if the package is in range, if specs pass with the new version. It stays silent, but if it releases a version that is not covered by your semver or breaks your specs, it does a PR

[AsaAyers]

👍 ok, sounds good to me. Users will be getting the updates either way, greenkeeper is just making sure it doesn't break. I like the sound of that.

[Arcanemagus]

Yep, that's the whole idea behind greenkeeper 😉

It only speaks up when something is broken (bad dependency update within your allowed range), something is new (version out of your range), or it has no idea what is going on (no specs).

[lucasdf]

I have reviewed the list and the following entries can be updated:

Specs implemented

These packages have specs now so they can be marked as completed:

• linter-hlint
• linter-puppet-lint
• linter-elixirc
• linter-coffeelint
• linter-tslint
• linter-lsc
• linter-pycodestyle (is is added as linter-pep8 in the list)

No CI configured

These packages have specs but there is no CI configured:

• linter-lsc
• linter-pycodestyle

Not on the list and no tests

These packages are not in the list but they exist and do not have specs:

• linter-spell-word-list

Deleted packages

These packages have been deleted, so they should be removed from the list:

• linter-twig-lint has been deleted

[Arcanemagus]

Thanks @lucasdf for that! I've updated the list, although I left linter-lsc and linter-pycodestyle unchecked for now as they don't have active CI checking that it is actually working.

[Arcanemagus]

Added a project to track the remaining packages:
https://github.com/orgs/AtomLinter/projects/5

[Arcanemagus]

I'm going to close this issue as it was only meant as a status tracker, which is handled much better in the organization project.