Starting with npm version 5, npm install will generate a lockfile
(now named package-lock.json) or update the existing npm-shrinkwrap.json
To prevent changes being generated in the codebase when this happens, we
need to commit the version 5 generated shrinkwrap.
This is related to a general overhaul [1] of how npm manages things. But
for our purposes, we the lockfile should be BC to previous versions [2].
Going forward, we need to ensure we generate the lockfile on npm >=5 to
prevent differences from the previously un-versioned lockfile.
[1] http://blog.npmjs.org/post/161081169345/v500
[2] https://github.com/npm/npm/issues/16728#issuecomment-305104149
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)
Unfortunately the engine requirement in packages.json is not a fatal
error, so you can get unhelpful errors with grunt if using an
unsupported version.
* We bump our minimum node version up to >=4. Although this isn't yet
necessarily *required* it was spurred on because grunt dropped support
for very early node versions and so it's likely some devs will have to
upgrade their npm.
We do it now which gives us more flexibility for tools going forward
(especially for things like new theme/testing). And node has matured
the ecosystem (especially supporting properly semver) so should result
in less edge cases.
* We make the minimum node version explicit in package.json. Though it
doesn't help much for older versions of node because npm doesn't
have the functionality to warn about it.. ;-)
* Left async dependency as it was, because it's only on an RC: 2.0.0-rc.6
1) Parse thirdpartylibs.xml and generate an array of third party
file paths to use in grunt tasks
2) In the lint tasks, we filter third party files from being linted
3) We add a new task to generate ignore files - currently for eslint,
but will be potentially useful for other things in the future
4) Remove .eslintignore from source control
Why have the ability to generate a .eslintignore file? For tooling
integration - by having the eslintignore file people can use other
eslint tools without having to just use grunt (e.g. editor
integrations).
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.
Includes multiple changes to the shifter task to simplify and
support this:
* Use grunt.file for shifter yui 'module' detection rather than our own
70 line function
* Use grunt.util.spawn rather than our own exec for shifter
* Improve behaviour on various yui subdirectories
We have to add the 'async' depndency to npm because we are running
multiple async operations in the single task. We use async.eachSeries to
run each shifter job sequentally (else the output would be unreadable
when running async).
We also run shifter in non-recursive mode on the module directory so its
not building everything (thanks to Ryan for pointing this out!)
We've tried various approaches to lock down our dependencies and they
have been flawed because dependencies in our included packages may not
be locked down and previous attempts to do that have not been correct.
With npm shrinkwrap we lock down versions so that any npm install will
always install the exact same versions for all developers - see:
https://docs.npmjs.com/cli/shrinkwrap
(This is a lot like composer.lock for those more fluent with composer)
