This linter, nixf is part of nixd, a nix language server. By using it, we will output the same diagnostic message as nixd, mainly:
Better parsing error in some cases, like missing semicolon and unexpected character at line end
Unused code, like arguments, variables, rec, with, etc
Escaping with (use of external variables inside with, which can easily cause ambiguity). This can be part of avoiding overuse of with. (This may be postponed until we reach consensus on handling with in many aspects)
This workflow is the same as the checking format one, and will only check files that did not have problems in the past, as well as newly created files. But after a few rounds of treewide, we can minimize the existing files with problems, so hopefully we will get a cleaner codebase.
This feature is still in the experimental stage, and may encounter edge cases or areas where people are dissatisfied. Feel free to remind me (@Aleksanaa) and @inclyc under PR where problem occurs. We will actively fix these issues and focus on future improvements.
This workflow can also be provided as a separated GitHub action in the future to enpower other similar projects at the same time. If anyone would like to do this, they are more than welcome.
Many thanks to @inclyc for developing such a powerful tool, and @Infinisil for telling me this very crucial GitHub feature that makes it work like a charm!
Maybe I should write a wrapper to achieve a similar effect to deadnix. The current rendering is implemented using a jq expression, which may be a bit lame in our toolbox because I need to write another jq expression to make it more human friendly
Maybe just use nixd the language server, it shares the frontend with nixf-tidy, and we don’t need worry about rendering because diagnostics are rendered on man’s favorite editor.
We should set stricter rules for this. Of course, it is OK to output them in a different color, but I tend to think that this is an error for us, so let’s output it in the error color.
Neat, i’m still unsure but lets see how it goes. My greatest fear is that we end up unable to merge the plethora of otherwise good drive-by contributions whose authors are often unresponsive to review feedback.
We can’t do anything about this, for example, they don’t format, write non-standard commit messages (I can still tolerate this, using squash merge). In this case, there is no difference between the reviewer pointing out that there is an unused variable and CI pointing out it, and the latter is even more efficient.
Of course they should not be bothered by existing errors, because the files with errors before editing will be ignored. If their submission is an important fix but they made some mistakes, there will be a committer to help them deal with it.
Regarding this, I’m willing to sit down, run the linter on all packages, and fix them one by one. I could do this as a chore for about 10 minutes daily or such. It would take months depending on how many packages “break”, but I guess once it’s all cleared up, the CI wouldn’t need to try and ignore existing issues.
Nevertheless, I’m not sure how much of this is worth than putting my time towards something considered more important.
Oh also, although my CI does not extract it, nixf-tidy actually includes the suggested fix information which can be processed with a script. It currently does not support unused variables, but that should also be trivial.
