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 enables the Gherkin-lint rule to prevent the use of
"Examples" in a Scenario.
The Example tag is only allowed in a Scenario Outline at this time and
their use in a Scenario has no meaning.
This change enables the gherkinlint rule to require a new line at the
end of the file. This change is in keeping with existing Moodle coding
style guidelines.
The gherkin-lint package now understands the use of "Examples" and
requries that their indentation be correct and consistent.
This change sets the indentatation for these to:
"Examples": 4,
"example": 6,
This is in-line with the examples given in the offical Cucumber/Gherkin
documentation at
https://cucumber.io/docs/gherkin/reference/#scenario-outline whereby the
Examples and individual rows of the Examples table are children of the
Scenario outline.
This is contrary to the default for Gherkin-lint which places them as
top-level nodes with an indentatio of 0, and 2 respectively.
This CSS statement was an MS-only rule which was never accepted, and
which was abonded some time before IE 10. It has no effect in supported
browsers and can be safely replace with `opacity: [0.0-1.0]`.
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.
I've modified the Google Drive portfolio export so that it creates a
root directory in Drive for all of the files in the export. This allows
each export to be contained from each other to help with clashing file
names.
Additionally, the paths for the exported files will now be created in
Drive so that exported files are in the correct directory structure.
This is important for forum posts exports which assume a certain
directory structure in the export.
There are some changes to make this possible:
- Enable by default the Mobile notifications plugin
- Implement a new callback for core -> plugins communication
- Generate an Airnotifier access key in the callback when needed
In fact, rather than fix the old logic, I noticed that the correct
logic was already implemented in get_users_by_capability. So, I
refactored to extract the working version into a function, which it
turns out can have exactly the same API as get_with_capability_join,
which was convenient.
