https://github.com/200ok-ch/oklint
A rather generic, easily extendable linter for everything:tm:
https://github.com/200ok-ch/oklint
Last synced: 4 months ago
JSON representation
A rather generic, easily extendable linter for everything:tm:
- Host: GitHub
- URL: https://github.com/200ok-ch/oklint
- Owner: 200ok-ch
- License: agpl-3.0
- Created: 2020-03-14T18:16:43.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2020-03-14T18:17:06.000Z (over 5 years ago)
- Last Synced: 2025-03-13T14:13:28.685Z (7 months ago)
- Language: JavaScript
- Size: 134 KB
- Stars: 2
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.org
- License: LICENSE.md
Awesome Lists containing this project
README
* oklint
A rather generic, easily extendable linter for everything™.
#+ATTR_HTML: :style float:right;
[[./oklint_logo.png]]
** Introduction
=oklint= is not just another linter.
/lint, or a linter, is a tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs./ ([[https://en.wikipedia.org/wiki/Lint_(software)][Wikipedia]])
=oklint= doesn't lint source code, at least not first and foremost.
=oklint= is an extendable linting system that aims for linting
everything. Sounds presumptuous? It totally is! But listen...
The thing is, we wanted to ensure that in a Git repo on commit
- files are named according to a schema
- csv files are well formed and fit for automatic processing
- certain keywords are present in every line of a file
- etc (you get the picture)
As you can see, we took linting to another level. We wanted to lint
all-the-things!
** Usage
=oklint= comes with a couple of plugins. If you don't find what you
need it is relatively straight forward to develop you own plugins for
=oklint=. It currently provides plugins for
- filenaming
- csv
- timesheet_tagging
The rules are stored in YAML files called =.oklint= and applied on a
per-directory basis. You can lint a single file against these rules
by calling =oklint= with the path as an argument.
#+BEGIN_EXAMPLE
% find
.
./.oklint
./some-file.txt
./other-file.TXT
% oklint some-file.txt
Applying rules from .oklint...
Applying plugin filenaming...
#+END_EXAMPLE
Or you can just call without arguments to have it scan for all
=.oklint= files and run the rules found again just the changed files
in the repository. (This lowers the barrier to introduce new rules as
they will only be applied to newly created or changed files.)
#+BEGIN_EXAMPLE
% oklint
Finding changed files via git...
Applying rules from .oklint...
Applying plugin filenaming...
#+END_EXAMPLE
If the command returns with the return value 0 everything is ok, which
means every defined rule is satisfied. Otherwise a non-zero exit code
will be returned.
We recommend using =oklint= in a Git repo with Git's pre-commit hook,
which will prevent commit which do not fully satisfy the defined
rules.
As a matter of fact =oklint= currently assumes that it is used in a
Git repo, because when called without arguments it uses Git to look
for changed files.
We recommend [[https://github.com/typicode/husky][husky]] to easily setup the git hook. This in your
=package.json= should do:
#+BEGIN_EXAMPLE
"husky": {
"hooks": {
"pre-commit": "oklint"
}
},
#+END_EXAMPLE
** License
see [[./LICENSE.md]]