Add Linter

[lee2sman]

Currently L5 is written with extensively documented code. But there are extra lines, different spacing at times. Probably it should use a linter, especially as additional people hack on the codebase. Other potential benefits: catch bugs like undefined globals, typos, unused vars. Automates some aspect of feedback for contributors and makes clear style rules.

Describe the solution you'd like
Consider luacheck (install with luarocks). It seems the most widely used and can work with GitHub CI/CD.

Describe alternatives you've considered
The more build tools get added, the more complexit for 'getting started' on the codebase, so how much this benefits the project (or not) should be considered.

[Nitish-bot]

hey @lee2sman I would like to take this issue up, right off the bat I think the benefits of a linter so greatly outweight the cost that it's not even close. I think a formatter should go hand in hand with a linter to ensure consistency through and through.

Although, I would suggest we use selene instead of luacheck, and even though the former has descriptive errors, is more extensible, faster and customizable, I mostly reason because the latter hasn't seen any activity in 8 years.

Luacheck attempts to lint for long lines and whitespace which selene considers a concern of the formatter, for which we could use stylua.

Both projects have seen activity as recently as last week, are written is rust. Only caveat being that installing selene requires cargo which is the package manager for rust, I don't think it's a big deal but I would like to hear your thoughts on this.
We could also use the prebuilt binaries available in their GH which I think would be a good middleground if we're trying to steer clear of the rust toolchain.

Also the minimum supported lua version is 5.1, I wasn't able to find out which version the projects uses. I'm sorry if this is obvious, I am a first time lua writer.

[lee2sman]

Hi @Nitish-bot thanks for your helpful thoughts and feedback here and on your other issues and pull requests. I appreciate being able to tease these out and talk it through.

In keeping with values of minimizing resource usage, and allowing L5's use on as wide a variety of machines, including older and less-resource-intensive computers as we can, I do not want to require a Rust toolchain. Also, I want to acknowledge that there is a tension point between how I think L5 should work and how many open source software projects work, with lots of CI/C pipelines, build systems, AI bots, toolchains, etc. These kinds of things increase resource usage on a machine, add complications for development, increase resource consumption/energy usage.

For more on the thinking around this, check these two posts on the Permacomputing wiki:

• Build on Solid Ground
• Consider carefully the interaction between simplicity, complexity an scale

I also want to mention that in the Lua ecosystem, it's fairly common to find older libraries that haven't been changed in years and years. And yet they still work fine. In JavaScript, developers constantly fiddle with tools and work on libraries. They constantly change their code, their dependencies, and they break, need to be changed and updated and managed. With NPM, then with NVM. Yarn. Deno. Etc. Then in a few years that library is discarded. Lua and its ecosystem is really different from this. Slow to change. Minimal resource consumption. Efficient. These are important and why L5 is built with Love2 an Lua as its stack.

Love2d currently uses LuaJit 2.1 on most installations, with a few exceptions.

Let's keep the dialog going. I value the conversation, and I think it will help us hone what we are doing, and get closer to making decisions on ways to refactor or make needed changes.

[Nitish-bot]

@lee2sman the pleasure is mine, absolutely love everything that is to do with the processing foundation.

I feel like you misunderstand the job of a linter/formatter. They're what JS calls dev dependencies, only the people working on L5 (let's call them contributors) need to install them, the end user experience remains unchanged regardless. Unless you mean to provide the users an option to lint their own code too in which case installing luacheck is more or less the same amount of hassle since the user has to setup luarocks.
As I mentioned, we can always just use the prebuilt binaries if we want contributors to not face that hurdle, which in my opinion is not a big one. I could easily write a very simple script that pulls the prebuilt binaries from github releases and adds them to PATH, but again installing via cargo is way easier and you can expect that of a developer/contributor. Adding a contributor guide to the repo will make this information clear to any contributor.

I understand you feel strongly about minimizing resource usage on the end consumer machine, but all of these things like CI/CD pipelines, build systems, AI bots/reviewers they only affect the person writing L5 not using L5. Your aversion to these things will only hinder the project in the long run, they're an open source standard for a reason. The user experience remains unchanged, the contributor learning curve might steepen slightly at the cost of increasing the project's longevity by making it hard to break and easy to understand.

The argument I make for selene is beyond the fact that it's currently actively maintained as I mentioned in my original comment. Consider giving this luacheck comparasion from the selene documentation a read.

And we're bang on with compatibility too. Selene and StyLua both support code written for LuaJIT (which itself is more or less compatible with Lua 5.1).

[lee2sman]

Still under consideration. Thanks for your patience.
FYI Luacheck is maintained. It was forked after the founder passed away.

You're right, there's a difference between contributors and users programming with L5. But I'm still trying to maintain minimal dependencies. And I am trying to mindifully adopt some standards and eschew others when they diverge from values/principles I am trying to achieve with L5. That could be spelled out better somewhere else.

[Nitish-bot]

I understand your approach, I'd be happy to work with either tool, since I see them only as a means to an end. I've already laid down why selene makes sense to me and I really think you too will be convinced of it if you read the luacheck comparison I linked in my previous comment. In any case, I'd be happy to implement it as and when we have a decision on it.

Off the topic, I was curious if there is another communication channel besides GH, I was hoping to get my GSOC proposal reviewed by you before the final submission if you're open to that.

[lee2sman]

To get GSOC feedback on your proposal, linked from the top post on this thread you can submit via this form.

[lee2sman]

In terms of a linter, here's some thinking about how this fits into the wider picture and why it may diverge from how other open source software projects would decide.

Imagine you are trying to have your L5 program work in 10 or 15 or 30 years. How can we design for this? My thinking and implementation is based on minimal dependencies, keeping things smaller, the entire library theoretically knowable and examinable in one's head, and building on 'solid' ground (Lua) and throwing our lot in with Love2d - a long-running, slowly-changing, open source project.

Developing/contributing is not the same as 'end user programming' - but we still need our tools to be consistent and work for the longterm. And I think slowly or rarely changing software is probably best.

And while this can't be guaranteed, using quickly changing software, or new (less than a couple years old), is not my favored way for working on L5 and its ecosystem. The boring, conservative choice (pin versions, minimal rules, don't use plugins you don't need) age much better than chasing the ecosystem. Lua changes slowly, and it appears Luacheck is fairly stable, not chasing new features. That's probably a good sign for longevity.

This same kind of thinking guides many of the other choices for L5.

[Nitish-bot]

Hey! Thanks for bearing with me on this and actually taking the time to consider. I understand where you come from and I think you also know by now that I'm the kind of guy to go get the bleeding edge even if you know it bleeds.

I think I've come to better understand and align my expectations with the vision you have for L5. Even though I still have my reservations on some of the things like CI/CD and modules which are not only a convenience but also a guardrail against unintended consequences, I trust your judgement as creator of the project.

And the fact that luacheck is still being maintained is all the more a green light for us to go with it. I still don't like how it tries to format your code which is not what the job of a linter is and even then it only provides whitespace and line length formatting options, I would prefer we disable formatting and use it in conjunction with StyLua which is a dedicated formatter.

It has way more options like line endings, indent type and quote style. These will make the code way more consistent and enforce the rules instead of hoping contributors follow them and we don't miss any patterns on PR reviews. It is a fairly mature project (over 6 years old) and also, it can be installed using prebuilt binaries from Github releases so no overhead on that part.

I can get on it as soon as I hear your thoughts and close #12 lest we drown the author in merge conflicts.