Add clj-kondo hook and config for linting defcomponent
#52
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hej! Thanks for providing Dumdom! I am having a blast with it.
This PR adds configuration for linting the
defcomponent
macro with clj-kondo. clj-kondo will, upon request, import it and. For people using cljure-lsp, clj-kondo will be requested to do so, and basically thet will not need to do anything but commit the config to their repositories.In my work project we're currently using an adapted
defcomponent
macro which lends itself to being linted asdefn
. The config submitted here improves on that solution by not requiring Dumdom users to include such a macro, offering some help with getting the life-cycle hook keywords right, and generally is less confusing.It's my first clj-kondo hook and I'm a bit wary that I'm doing something stupid (I often do!), but things behaves nicely with every test I throw at it.
A thing I am not sure I got right is the choice to lint life-cycle hook keywords as warnings. It could be errors as well, but at least I am in the habit of renaming things temporarily to disable some behaviour and then it makes sense with warning. I think users can override this with project local config.
I'm planning to write some more hooks for event code navigation and checking, but I think those will be better served as examples, because they will depend on what particular framework people set up with the global event handle. At least I think it will depend on that, I guess I will know better once I've started working on the hooks.