tink: Implement `tink lint`

help-wanted
good-first-patch
tink

(Kat Marchán) #1

This one should be fun and relatively small!!

Your mission, should you choose to accept it, would be to come up with and implement tink lint aka the default, built-in linter for tink! The idea is to come up with a baseline linting strategy and apply it across the board. Eventually, users will be able to provide their own scripts on top of this, but I’d like to start with a zero-config, reasonable-enough linting rule setup.

Most likely, this looks like eslint:recommended rules for eslint, which are meant to be relatively unopinionated but catch potential bugs and major readability issues.

We would be incorporating eslint directly into the project, and users will be able to call tink lint themselves to run it on their project. The end result should be a widespread increase in code quality (or at least in random persons getting annoyed at us). Either way, it’s a win, so let’s do this!

If you’re interested in picking this one up, just reply below and claim it and it’ll be yours as long as you don’t take several weeks to get around to it. Thank you in advance, and as always, I’m here to answer questions and provide support to anyone who’s kind enough to be donating their time to help me with this. Have a good one!


(Sam Collard) #2

I’d be excited to pick this up :grinning:


(Kat Marchán) #3

Then get hype cause it’s all yours!


(Sam Collard) #4

Found some time for an early dig around on this. Wanted to check a couple of things:

  1. For running lint/typecheck that’s specified in the project, I’ve made some nice headway with libnpm.runScript. Just wanted to make sure I’m not barking up the wrong tree there :slight_smile:

  2. For defaulting to eslint:recommended, we need to pull in ESLint. Would that be adding ESLint as an explicit package dependency (which I think means it’ll be pulled down as part of the initial npm i tink/npx tink?) or can we require it dynamically with tink’s own magic?

Also, wanted to check whether you were expecting it to call the ESLint Node API or shell out to run the ESLint command. I could see arguments either way, and was wondering if you had a strong preference for/aversion to either option.


(Kat Marchán) #5
  1. This sounds good, yes.
  2. Yes, a regular dependency. Ideally, you’d find a way to allow users to override the version with one in their project (might be a good way about this with runScript), but that can be just them adding their own lint script, rather than them installing an eslint version and expecting our script to work. tl;dr if there’s a lint script, we use that, otherwise we default to the built-in eslint.
  3. You’re better off running both of them as scripts if possible.