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
Progress bar styling has been removed as they do not appear to
be used anywhere, though MDL-56095 has been created to style them
as (with or without the styles) they remain unstyled.
The file responsive.scss has been removed, it was not used.
Part of MDL-55071
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.
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) 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).
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.
Because we don't have the entire YUI rollup, we can't apply some of the
rules safely, so we ignore some rules.
At this point I am not 100% certain this configuration is robust enough,
to deal with the lack fo rollup knowledge although its a good sign that
there are no errors on our entire yui codebase.
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.
Windows users are not able to run grunt on a subpath due to platform
restrictions. So we provide this option to provide a workaround for that.
Thanks to Ty Delean who proposed this idea.
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 mess around with the cwd to find a shifter path, not ideal but avoids
having to refactor the shifter task.
Also fix jshint errors..
1) The gruntfile runs in a nodejs environment and not a browser
environment.
2) There was an uninitialised variable
This is in preperation for the watch task and doing a few things:
1) Switch away from 'grunt.file.expandMapping' to the declarative syntax
for doing the same thing, as recommended in docs:
http://gruntjs.com/api/grunt.file#grunt.file.expandmapping
2) Factor the renaming function into shared function so it can be used
from the watch task too.
3) Shared the file glob'ing pattern for match AMD js files between
jshint and uglify task (this removes the node_modules exception..
we should add it to both if we need it).
4) Rename the task configuration - I am just doing this because it looks
like 'dynamic_mappings' is some how magic config option when you
look at the manual:
http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically
But in fact, it's just a task confguration name.
Two reasons for this change:
1) The configuration here is confusing, it seems like we are setting the
'files' option, but in fact we are just generating a task configuration
called 'files'. Lets try and avoid confusion.
2) It makes it possible for 'watch' to override the src
* Introduce the 'css' task - this will give us flexibility to do things
in future rather than relying on the inbuilt 'less' task (e.g. sourcemap
generating task which doesn't run by default)
* Introduce 'amd' task which runs only amd tasks
* Introduce 'js' task which runs all JS (amd/shifter) tasks
* Tweak the ordering so that slow shifter always runs last (useful for
people like me who forget to specif the task)
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).
Unfortunately, this is not perfect yet. It will build the entire
repository every time - which takes a while because it builds all the
yui modules (On linux it correctly only builds whats in the current dir).
