We add a new theme config so the theme can say it supports font-awesome.
If this is true, the pix_icon renderer will call a mapping function to map
from the moodle style t/edit to a font-awesome style fa-cog icon name. Then the renderer
will either render an image tag for old icons - or an accessible font-awesome <i> tag.
This mostly works - but there are some places where we don't use the pix icon renderer, and
we directly create image tags with pix_url image sources. These will need updating (Atto icons,
drag and drop move icons, editpdf icons).
The videojs javascript is over 1MB of javascript which we don't need to
load on every page, now that we only require it demand, the js can be
lazily loaded when its needed, which keeps the first.js smaller and more
likely to stay in browser cache.
The previously used minification libraries were:
a) Unmaintained
b) Had some silly licensing issues (MDL-36457)
The new library is smaller, maintained, active and GPL-compatible.
No changes from the upstream version have been made, it is recommended by
upstream to install these depdencies via composer - but the composer
installation is bundled with a load of test files, shell scripts etc (and
we don't use composer to manage 'production dependencies') so we have to
do it manually.
The SDK that this plugin was designed around is not compatible with recent
versions of Alfresco so the decisio has been made to move the repository to
the plugins database.
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).
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.
