Good job guys - I do think there's space for a broadly applicable solution in this space. The main selling points for a solution in this area, for us, are:
(1) a strong remote registry implementation (available hooks, preferably auto-matched to auto-detected languages present, perhaps using file/libmagic and language syntax versioning); and
(2) the ability to spec default behavior remotely in a company-wide registry, but then to override at two levels: that of checked in files within the repo, and .gitignore'd local developer-specific prefs.
I'm definitely going to look at this further. To speed adoption, I'd encourage you to avoid assumptions around people's de-facto desire for all but the most basic levels of linting (iffy warnings, etc.), ie. make sure the defaults are very light touch ... but useful. Convenience is key.
However, please don't encourage curl-based installs!
(1) a strong remote registry implementation (available hooks, preferably auto-matched to auto-detected languages present, perhaps using file/libmagic and language syntax versioning); and
(2) the ability to spec default behavior remotely in a company-wide registry, but then to override at two levels: that of checked in files within the repo, and .gitignore'd local developer-specific prefs.
I'm definitely going to look at this further. To speed adoption, I'd encourage you to avoid assumptions around people's de-facto desire for all but the most basic levels of linting (iffy warnings, etc.), ie. make sure the defaults are very light touch ... but useful. Convenience is key.
However, please don't encourage curl-based installs!