Using plone.recipe.codeanalysis for jshint

I'm using this recipe for flake8 checks currently. While my IDE should handle all of the js/css linting, it would be nice to have this as part of gitlab-ci/travis-ci. I have the below in my buildout for jshint.

[code-analysis]
recipe = plone.recipe.codeanalysis
directory = ${buildout:directory}/src
return-status-codes = True
flake8-exclude = openxmllib,Products.OpenXml,scripts,docs,collective.recipe.filestorage
jshint = True
jshint-bin = ${buildout:bin-directory}/jshint
# CSS
csslint = True
csslint-bin = ${buildout:bin-directory}/csslint
# ZPT
zptlint = True
zptlint-bin = ${buildout:bin-directory}/zptlint

[jshint]
recipe = gp.recipe.node
npms = jshint
scripts = jshint

[node]
recipe = gp.recipe.node
npms = csslint jshint jscs tslint
scripts = csslint jshint jscs tslint

When I run bin/code-analysis I get

JSHint.............................[ SKIP ] in 0.687s

Is there supposed to be a binary created for e.g. jshint? Or is that meant to already be created through some other means? After running buildout I do not have a script named jshint in the bin-directory

Was your jshint part for testing? Usually it is enough to have the node part declaration as defined in buildout.plonetest:

[node]
recipe = gp.recipe.node
npms = csslint jshint
scripts = csslint jshint

And yes, the jshint binary should be available. Is your node or jshint part included in the buildout parts?

You either have to install jshint via your system packages/npm/whatever or via buildout (as Thomas already recommended).

Question: Is jshint still a thing in the JS world? I was under the assumption that eslint is the de-facto standard in the JS community (React, Angular, Vue, ...) for years now.

Disclaimer: I wrote p.r.codeanalysis. Though, I personally think that JS code analysis should happen in the node ecosystem. We use husky/lintstaged in Volto and all our internal projects:

There is no way that p.r.codeanlysis can compete with a modern JS toolset. A modern JS linting toolset does everything I always imagined p.r.codeanalysis would be able to do in a bright future (proper pre-commit hooks installation, running lint/tests only on changed code, ecosystem for plugins and extensions, ...).

p.r.codeanalysis is fine for Python-related checks and tooling. Though, we should keep JS stuff out of it IMHO. I will not actively remove the JS stuff from p.r.codeanalysis. If people find it useful they can continue to use it. I would just not recommend it in 2020.

Thanks, I wasn't clear from the docs what needed to be included in the parts section. I had tried including jshint in parts and also installing in npm globally and that did not have any effect. Adding node to the parts section worked (in retrospect, adding jshint through npm probably would have worked if I didn't set jshint-bin to that path).

I mainly mentioned jshint here, but I was also interested in getting csslint and zpt/chameleon lint done through this. How do you feel about those tools in 2020? It looks like csslint requires a lot of exclusions to not be ridiculous and zptlint hasn't been updated in forever so it doesn't work in. Maybe move to Chameleon lint?

Plone Foundation Code of Conduct