Open klonos opened 6 months ago
I've assigned this issue to me for now, because I wanna try the JSHint GHA and configuration that @indigoxela has provided for https://github.com/backdrop-contrib/tinymce in this Zulip thread: https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/JavaScript.20linting.20tool (thank you 🙏🏼 )
@indigoxela:
After some experiments, I'm now happy with JSHint.
- No opinionated code style weirdness (doesn't actually care much about code style)
- Spots actual problems in code
- Super easy to integrate in a GitHub Action workflow
- Disadvantage: needs npm to install, but... :shrug:
Here's a workflow that integrates it: https://github.com/backdrop-contrib/tinymce/blob/1.x-1.x/.github/workflows/code-checks.yml#L35
To get nice inline annotations on Github for found errors, I had to create a custom report style, but that was easy:
https://github.com/backdrop-contrib/tinymce/blob/1.x-1.x/.github/misc/reporter.js
So if anyone else is interested in such a GHA, just go for it. :wink:
@herbdool:
Maybe for core?
@indigoxela:
Maybe for core?
Maybe... but we'd have to settle on a ruleset, which might take some time. https://github.com/backdrop-contrib/tinymce/blob/1.x-1.x/.jshintrc
And then we'd have to exclude all the third-party stuff... and finally fix all violations in our js code. Quite some effort...
Oh, almost forgot, you'll also need the options documentation to fiddle your own jshintrc:
Here's a rough, PoC PR that runs ESLint on PRs: https://github.com/backdrop/backdrop/pull/4655
.github/workflows/.eslintrc.json
config file that I've used is the exact same as the one that ships with latest Drupal 11.x. Not sure if we want/need the same kind of checks, so that will need some clean-up and tweaking, and decide which checks we need for Backdrop..github/workflows/package.json
file, as it expects to find that file in the root of the repo. For now, I've found a workaround, which is to include things that would otherwise go into the devDependencies
section of the package.json
file by installing them directly in the GHA via run: npm install eslint eslint-config-airbnb-base
.core/misc/dialog.js
in our codebase, and added a dummy comment line to it. This will need to be reverted - no linting is to happen as part of this PR.Next step is to tweak the implementation to be using something like https://github.com/grvcoelho/lint-diff. Here's why:
ESLint is a great tool to enforce code style in your code, but it has some limitations: it can only lint entire files. When working with legacy code, we often have to make changes to very large files (which would be too troublesome to fix all lint errors) and thus it would be good to lint only the lines changed and not the entire file.
lint-diff receives a commit range and uses ESLint to lint the changed files and filter only the errors introduced in the commit range (and nothing more).
If we can get that to work, then we can commit this and start using it. If we can't get this to work, we'll nee to come up with a plan to introduce this in core PRs without being disruptive. Perhaps exclude all files and start to gradually lint one file/module at a time(?).
For completeness, I will also try to get a PR going that uses JSHint, and we can compare which one we like the most. I don't think that I will bother creating a PR for JSLint though.
This is a follow-up to #5578, where it was proposed to remove the JSHint files from our codebase, since we aren't using them. The goal here is to add a GHA that checks our JS code, same as we have one checking our PHP code.
Available options:
eslint-disable
to ignore things (similar to// cspell:disable
/// cspell:enable
we are using to ignore words in CSPell).I saw this in one of the sources, but wasn't able to confirm it:
Another issue that would be a nice-to-have with our JS linting is to be able to detect deprecated jQuery functions and provide suggestions for these (see #6248). Here's what's available:
eslint-plugin-jquery
plugin:no-jquery/deprecated
includes all known deprecated and removed code, and is updated as new releases of jQuery come out. You can instead use configs targeting specific versions of jQuery if you know the environment in which your code will operate. There is a config for all minor versions from 1.0 to 3.6 (deprecated-1.0
, ...,deprecated-3.7
). Deprecation configs are cumulative, so they include all the rules for jQuery versions below them.Sources
https://www.jslint.com https://jshint.com https://eslint.org
http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint https://web.archive.org/web/20130819215629/http://anton.kovalyov.net/2011/02/20/why-i-forked-jslint-to-jshint
D8 change record: Use ESLint to validate all Drupal JavaScript
https://stackoverflow.com/questions/6803305/should-i-use-jslint-or-jshint-javascript-validation https://www.sitepoint.com/comparison-javascript-linting-tools https://www.testim.io/blog/eslint-vs-jshint https://stackshare.io/stackups/eslint-vs-jslint https://medium.com/@sheldonled/from-jshint-to-eslint-8a0a135fa2bf https://www.quora.com/Which-is-better-JSHint-or-ESLint