This change bumps the version of Shifter that we use to the final
release - version 1.2.0.
I strongly doubt that there will be more releases, and this release was
over two years ago.
This version uses a newer version of Istanbul, and fixes to use that
specific version of Istanbul. As a result I have forked Shifter and
applied the Moodle Circular Dependency fixes there instead.
This version also inludes an upgrade to uglify from 1.3.x to 2.4.x. This
major upgrade includes a some changes to the built YUI module code.
This change updates most libraries used in our Grunt build stack and
applies necessary changes to Grunt and Gherkin-lint configuration to
ensure that they continue to work.
The grunt-sass plugin has been updated to support alternative
'implementations' of sass compilers, and the chosen sass compiler must
now be specified in the grunt configuration. We continue to use the
`node-sass` package for this.
Our gherkin-lintrc included two rules which were renamed from
'no-unamed-*' to 'no-unnamed-*'. This change occurred in version 2.0.0
of Gherkin-lint and has no other effect.
Shifter is using an ancient and no-longer supported of Istanbul. That
version contains a circular dependency whereby it fetches the version
from the index that included the file in the first place. This throws a
warning on newer versions of Node.
The fix here is simple and intended to be the bare minimum to remove
these warnings anad resolve the issue.
We have forked the istanbul project and created a v0.1.37_moodle branch
at the root version of the Istanbul version that Shifter uses (v0.1.37
tag). The circular dependency is then addressed and a new tag created.
I have then forked Shifter, pointing its package.json at the tar.gz
download of that new tag and pushed a new branch and tag for that fix.
Following this our own package.json is updated to point to the tar.gz
version of the new Shifter tag.
Version 14.0.0 has just been released as stable, and will make its way
to an LTS release which will be supported until 30th April 2023.
At time of writing it is the "Current stable" release and will remain in
this phase until 20th October 2020, at whciih point it will transition
to LTS status.
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!)
A) Remove direct dependency on uglify-js:
This dependency was added in MDL-50277, but it isn't quite correct, the
way npm installs dependencies means that grunt-contrib-uglify *could* use
'our' version if its satisifed. But does not *always* and especially does
not if the grunt-contrib-uglify requirement is higher than ours.
Long story short, in many cases this means that this is used:
node_modules/grunt-contrib-uglify/node_modules/uglify-js
But this is not:
node_modules/uglify-js
In MDL-50277 we thought we were making the version sticky, but in
reality we were just fixing previous problems by updating
grunt-contrib-uglify to a version which fixed a bug:
https://github.com/gruntjs/grunt-contrib-uglify/issues/313
It seems the better solution will come with using npm shrinkwrap to lock
down depdencies.
B) Bump grunt-contrib-uglify to 0.11.0
This moves us to uglify-js ~2.6.0 - which doens't change any output
files.
This version of grunt-contrib-jshint itself uses a better fixed
requirement on "~2.8.0" rather than "^2.8.0" which was giving variable
results with some people updating to 2.9-rc1.
See also https://github.com/gruntjs/grunt-contrib-jshint/pull/219
Previously we were using recess to build bootstrap base as it was what
was used by the original project. But recess is no longer maintained.
Now we use grunt for building js, it makes sense to use it for less too.
(If you really don't want to use grunt, you almost certainly can just
use lessc -x as it uses the same less.js on backend).
In order to produce a consistent build across the board, we must hardcode
several package versions. We must additionally specify compatible
versions for any sub-dependency that we have a requirement upon.
In this instance, the only sub-dependency which has an effect upon the
overall output is grunt-contrib-uglify's dependency upon uglify-js.
Since change in uglify-js may lead to changes in the generated output, we
must specify a fixed version of that dependency. That version must be
compatible with the dependency signature for grunt-contrib-uglify or the
dependency manager will just download a different version.
This issue also bumps the version of uglify-js to a version which changes
the output. This is the latest version at time of commit.
