All rules included in "eslint:recommended" set containing matching
values are removed from the list. Recommended set is defined in
node_modules/eslint/conf/eslint-recommended.js
To identify deprecated rules, temporary install sarbbottam/eslint-find-rules, then run
`npx eslint-find-rules -d .eslintrc`, it will return a list of rules
defined in .eslintrc that were deprecated.
Adding 'plugin:promise/recommended' results in 5k+ jsdoc warnings most
of which includes missing return and naming preferences (e.g. 'returns'
over 'return' or 'string' over 'String'). This needs to be audited and
addressed seprately.
This enables recommended rules and brings back related rules. Without
reducing level to warn for some of them, this gives numerous (about 88) issues mainly
catch-or-return. Recommended set is defined in
node_modules/eslint-plugin-promise/index.js
This change adds configuration for the eslint-jsdoc plugin in order to
detect the following errors with jsdoc blocks:
* missing params
* params in incorrect order
* params with no type defined
* properties incorrectly defined
* incorrect use of @package
* incorrect values for @access
In addition, warnings will be thrown where indentation is incorrect.
Prior to this change all Grunt features were in a single Gruntfile.js
but this has become difficult to manage and maintain.
This commit moves the existing dependencies for component calculation
and babel moduel definition into a new .grunt directory, and
restructures the existing tasks in Gruntfile.js into separate task
configuration files.
This improves the maintainability of the Grunt build system and allows
for easier future expansion.
Since ESlint 4.1.0 [1], it's possible to support glob-based
configuration, this means we can move glob configuration out of grunt
and into the config file, which means tools will respect the glob rules
now too. :)
[1] http://eslint.org/blog/2017/06/eslint-v4.1.0-released
1) Bump eslint verson in npm
2) Enable tabs rule introduced in 3.2.0
3) With rules deprecated in 3.3.0 to their replacements
http://eslint.org/blog/2016/08/eslint-v3.3.0-released
4) Deprecate the use of M.str (fixes MDLSITE-3646) with new
no-restricted-properties introduced in 3.5.0
5) Fixup no-unused-vars - remove argsIgnorePattern which shouldn't have allowed
partial matches and turns out to be uncesssary
(detected because of https://github.com/eslint/eslint/issues/7250 in 3.6.0)
Instead of using the more rollup-tolerant config for all files, make the
configuration stricter by default but lower in grunt for yui modules.
This means that manual runs (prechecker) or editor integrations will
flag up the errors as well as grunt.
Also add ignore lines to the core files so that eslint isn't noisy when
not running with grunt.
1) Allow jsdoc descriptions to be empty. I think that matches our phpdoc
checker, and I think its probably better than me filling the
descriptions in poorly.
2) For the captilisation rules, don't apply to object properties (this
is because jQuery has lots of violators of this rule)
Instead of having the stricter configuration for all files, use
the less strict default config and switch to the stricter config
for building AMD modules.
This means that the eslint commandline/editor inspections will work
better for all files and not generate false positives when using editor
integrations. But since grunt is required to build AMD modules we still
get the stricter checking for those files on build.
I have spent quite a lot of time working through the current list of
eslint options and configuring them for Moodle style and I think this is
a very good basis to start us at (as well as taking some of out jshint
options out with https://www.npmjs.com/package/polyjuice ). Thanks to
Andrew Nicols, Mark Johnson and Frédéric Massart for some refinements.
With this configuration the grunt build will fail if errors are present
in the js (though you can of course tell jshint to ignore some errors,
as I have done in admin/tool/lp/amd/src/competency_rule_points.js and
defining the Y global in lib/amd/src/yui.js ).
The grunt task will not report warnings by default, but a new
--show-lint-warnings flag will help achieve that. Editor
integrations/stanadalone eslint tool will surely be a better way of
getting eslint errors rather than using the grunt task.
