The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
tink: Implement `tink lint`
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!
I’d be excited to pick this up
Then get hype cause it’s all yours!
Found some time for an early dig around on this. Wanted to check a couple of things:
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
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.
- This sounds good, yes.
- 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.
- You’re better off running both of them as scripts if possible.