mirror_php/moodle
1
0
Fork 0
mirror of https://github.com/moodle/moodle.git synced 2025-01-17 21:49:15 +01:00
Code Issues Projects Releases Wiki Activity
moodle/npm-shrinkwrap.json

3171 lines
108 KiB
JSON
Raw Normal View History

MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
{
"name": "Moodle",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"lockfileVersion": 1,
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
"dependencies": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"abbrev": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.0.tgz",
"integrity": "sha1-0FVMIlZjbi9W58LlrRg/hZQo2B8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"acorn": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "5.0.3",
"resolved": "https://registry.npmjs.org/acorn/-/acorn-5.0.3.tgz",
"integrity": "sha1-xGDfCEkUY/AozLguqzcwvwEIez0=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"acorn-jsx": {
"version": "3.0.1",
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"resolved": "https://registry.npmjs.org/acorn-jsx/-/acorn-jsx-3.0.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-r9+UiPsezvyDSPb7IvRk4ypYs2s=",
"dev": true,
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"dependencies": {
"acorn": {
"version": "3.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/acorn/-/acorn-3.3.0.tgz",
"integrity": "sha1-ReN/s56No/JbruP/U2niu18iAXo=",
"dev": true
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
}
}
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"ajv": {
"version": "4.11.8",
"resolved": "https://registry.npmjs.org/ajv/-/ajv-4.11.8.tgz",
"integrity": "sha1-gv+wKynmYq5TvcIK8VlHcGc5xTY=",
"dev": true
},
"ajv-keywords": {
"version": "1.5.1",
"resolved": "https://registry.npmjs.org/ajv-keywords/-/ajv-keywords-1.5.1.tgz",
"integrity": "sha1-MU3QpLM2j609/NxU7eYXG4htrzw=",
"dev": true
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"align-text": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/align-text/-/align-text-0.1.4.tgz",
"integrity": "sha1-DNkKVhCT810KmSVsIrcGlDP60Rc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"amdefine": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/amdefine/-/amdefine-1.0.1.tgz",
"integrity": "sha1-SlKCrBZHKek2Gbz9OtFR+BfOkfU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"ansi-color": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ansi-color/-/ansi-color-0.2.1.tgz",
"integrity": "sha1-PnXAN0dSF1RO12Oo21cJ+prlv5o=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"ansi-escapes": {
"version": "1.4.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-1.4.0.tgz",
"integrity": "sha1-06ioOzGapneTZisT52HHkRQiMG4=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"ansi-regex": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.1.1",
"resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-2.1.1.tgz",
"integrity": "sha1-w7M6te42DYbg5ijwRorn7yfWVN8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"ansi-styles": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-2.2.1.tgz",
"integrity": "sha1-tDLdM1i2NM914eRmQ2gkBTPB3b4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"argparse": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.9",
"resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.9.tgz",
"integrity": "sha1-c9g7wmP4bpf4zE9rrhsOkKfSLIY=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"array-differ": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/array-differ/-/array-differ-1.0.0.tgz",
"integrity": "sha1-7/UuN1gknTO+QCuLuOVkuytdQDE=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"array-find-index": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/array-find-index/-/array-find-index-1.0.2.tgz",
"integrity": "sha1-3wEKoSh+Fku9pvlyOwqWoexBh6E=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"array-union": {
MDL-54944 eslint: Add rules from Policy decision Also bump eslint to v2.13.1 and make the version explicit in package.json
2016-06-28 21:03:27 +01:00
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/array-union/-/array-union-1.0.2.tgz",
"integrity": "sha1-mjRBDk9OPaI96jdb5b5w8kd47Dk=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"array-uniq": {
MDL-54944 eslint: Add rules from Policy decision Also bump eslint to v2.13.1 and make the version explicit in package.json
2016-06-28 21:03:27 +01:00
"version": "1.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/array-uniq/-/array-uniq-1.0.3.tgz",
"integrity": "sha1-r2rId6Jcx/dOBYiUdThY39sk/bY=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"arrify": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/arrify/-/arrify-1.0.1.tgz",
"integrity": "sha1-iYUI2iIm84DfkEcoRWhJwVAaSw0=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"asap": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.5",
"resolved": "https://registry.npmjs.org/asap/-/asap-2.0.5.tgz",
"integrity": "sha1-UidltQw1EEkOUtfc/ghe+bqWlY8=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"asn1": {
"version": "0.2.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/asn1/-/asn1-0.2.3.tgz",
"integrity": "sha1-2sh4dxPJlmhJ/IGAd36+nB3fO4Y=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"assert-plus": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-0.2.0.tgz",
"integrity": "sha1-104bh+ev/A24qttwIfP+SBAasjQ=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"async": {
MDL-49817 grunt: handle multiple watched files changed at once 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!)
2016-01-21 14:21:13 +00:00
"version": "1.5.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-1.5.2.tgz",
"integrity": "sha1-7GphrlZIDAw8skHJVhjiCJL5Zyo=",
"dev": true
},
"asynckit": {
"version": "0.4.0",
"resolved": "https://registry.npmjs.org/asynckit/-/asynckit-0.4.0.tgz",
"integrity": "sha1-x57Zf380y48robyXkLzDZkdLS3k=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"autoprefixer": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "6.7.7",
"resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-6.7.7.tgz",
"integrity": "sha1-Hb0cg1ZY41zj+ZhAmdsAWFx4IBQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"aws-sign2": {
"version": "0.6.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/aws-sign2/-/aws-sign2-0.6.0.tgz",
"integrity": "sha1-FDQt0428yU0OW4fXY81jYSwOeU8=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"aws4": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.6.0",
"resolved": "https://registry.npmjs.org/aws4/-/aws4-1.6.0.tgz",
"integrity": "sha1-g+9cqGCysy5KDe7e6MdxudtXRx4=",
"dev": true,
"optional": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"balanced-match": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.4.2",
"resolved": "https://registry.npmjs.org/balanced-match/-/balanced-match-0.4.2.tgz",
"integrity": "sha1-yz8+PHMtwPAe5wtAPzAuYddwmDg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"bcrypt-pbkdf": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/bcrypt-pbkdf/-/bcrypt-pbkdf-1.0.1.tgz",
"integrity": "sha1-Y7xdy2EzG5K8Bf1SiVPDNGKgb40=",
"dev": true,
"optional": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"body-parser": {
"version": "1.14.2",
"resolved": "https://registry.npmjs.org/body-parser/-/body-parser-1.14.2.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-EBXLH+LEQ4WCWVgdtTMy+NDPUPk=",
"dev": true,
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"dependencies": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"debug": {
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.2.0.tgz",
"integrity": "sha1-+HBX6ZWxofauaklgZkE3vFbwOdo=",
"dev": true
},
"iconv-lite": {
"version": "0.4.13",
"resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.13.tgz",
"integrity": "sha1-H4irpKsLFQjoMSrMOTRfNumS4vI=",
"dev": true
},
"ms": {
"version": "0.7.1",
"resolved": "https://registry.npmjs.org/ms/-/ms-0.7.1.tgz",
"integrity": "sha1-nNE8A62/8ltl7/3nzoZO6VIBcJg=",
"dev": true
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"qs": {
"version": "5.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/qs/-/qs-5.2.0.tgz",
"integrity": "sha1-qfMRQq9GjLcrJbMBNrokVoNJFr4=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"boom": {
"version": "2.10.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/boom/-/boom-2.10.1.tgz",
"integrity": "sha1-OciRjO/1eZ+D+UkqhI9iWt0Mdm8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"brace-expansion": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.7",
"resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.7.tgz",
"integrity": "sha1-Pv/DxQ4ABTH7cg6v+A8K6O8jz1k=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"browserify-zlib": {
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/browserify-zlib/-/browserify-zlib-0.1.4.tgz",
"integrity": "sha1-uzX4pRn2AOD6a4SFJByXnQFB+y0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"browserslist": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.7.7",
"resolved": "https://registry.npmjs.org/browserslist/-/browserslist-1.7.7.tgz",
"integrity": "sha1-C9dnBCWL6CmyOYu1Dkti0aFmsLk=",
"dev": true
},
"buffer-shims": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/buffer-shims/-/buffer-shims-1.0.0.tgz",
"integrity": "sha1-mXjOMXOIxkmth5MCjDR37wRKi1E=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"builtin-modules": {
"version": "1.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/builtin-modules/-/builtin-modules-1.1.1.tgz",
"integrity": "sha1-Jw8HbFpywC9bZaR9+Uxf46J4iS8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"bytes": {
"version": "2.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/bytes/-/bytes-2.2.0.tgz",
"integrity": "sha1-/TVGSkA/b5EXwt42Cez/nK4ABYg=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"caller-path": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/caller-path/-/caller-path-0.1.0.tgz",
"integrity": "sha1-lAhe9jWB7NPaqSREqP6U6CV3dR8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"callsites": {
"version": "0.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/callsites/-/callsites-0.2.0.tgz",
"integrity": "sha1-r6uWJikQp/M8GaV3WCXGnzTjUMo=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"camelcase": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/camelcase/-/camelcase-2.1.1.tgz",
"integrity": "sha1-fB0W1nmhu+WcoCys7PsBHiAfWh8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"camelcase-keys": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/camelcase-keys/-/camelcase-keys-2.1.0.tgz",
"integrity": "sha1-MIvur/3ygRkFHvodkyITyRuPkuc=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"caniuse-db": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.30000676",
"resolved": "https://registry.npmjs.org/caniuse-db/-/caniuse-db-1.0.30000676.tgz",
"integrity": "sha1-gupXgjdjfI/zSiisqt43O2JMTqg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"caseless": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.12.0",
"resolved": "https://registry.npmjs.org/caseless/-/caseless-0.12.0.tgz",
"integrity": "sha1-G2gcIf+EAzyCZUMJBolCDRhxUdw=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"center-align": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/center-align/-/center-align-0.1.3.tgz",
"integrity": "sha1-qg0yYptu6XIgBBHL1EYckHvCt60=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"chalk": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/chalk/-/chalk-1.1.3.tgz",
"integrity": "sha1-qBFcVeSnAv5NFQq9OHKCKn4J/Jg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"circular-json": {
"version": "0.3.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/circular-json/-/circular-json-0.3.1.tgz",
"integrity": "sha1-vos2rvzN6LPKeqLWr8B6NyQsDS0=",
"dev": true
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"cli": {
"version": "0.6.6",
"resolved": "https://registry.npmjs.org/cli/-/cli-0.6.6.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-Aq1Eo4Cr8nraxebwzdewQ9dMU+M=",
"dev": true,
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
"dependencies": {
"glob": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"version": "3.2.11",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/glob/-/glob-3.2.11.tgz",
"integrity": "sha1-Spc/Y1uRkPcV0QmH1cAP0oFevj0=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
"minimatch": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.3.0.tgz",
"integrity": "sha1-J12O2qxPG7MyZHIInnlJyDlGmd0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"cli-cursor": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/cli-cursor/-/cli-cursor-1.0.2.tgz",
"integrity": "sha1-ZNo/fValRBLll5S9Ytw1KV6PKYc=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"cli-width": {
"version": "2.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/cli-width/-/cli-width-2.1.0.tgz",
"integrity": "sha1-sjTKIJsp72b8UY2bmNWEewDt8Ao=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"cliui": {
"version": "2.1.0",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/cliui/-/cliui-2.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-S0dXYP+AJkx2LDoXGQMukcf+oNE=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"wordwrap": {
"version": "0.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.2.tgz",
"integrity": "sha1-t5Zpu0LstAn4PVg8rVLKF+qhZD8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
"clone-regexp": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/clone-regexp/-/clone-regexp-1.0.0.tgz",
"integrity": "sha1-6uCiQT9VwJQvgYwin+/OhF1/Oxw=",
"dev": true
},
"co": {
"version": "4.6.0",
"resolved": "https://registry.npmjs.org/co/-/co-4.6.0.tgz",
"integrity": "sha1-bqa989hTrlTMuOR7+gvz+QMfsYQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"code-point-at": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/code-point-at/-/code-point-at-1.1.0.tgz",
"integrity": "sha1-DQcLTQQ6W+ozovGkDi7bPZpMz3c=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"coffee-script": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.10.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/coffee-script/-/coffee-script-1.10.0.tgz",
"integrity": "sha1-EpOLz5vhlI+gBvkuDEyegXBRCMA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"color-diff": {
"version": "0.1.7",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/color-diff/-/color-diff-0.1.7.tgz",
"integrity": "sha1-bbeM2UgqjkWdQIIer0tQMoPcuOI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"colorguard": {
"version": "1.2.0",
"resolved": "https://registry.npmjs.org/colorguard/-/colorguard-1.2.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-8/rK9cquuk71RlPZ+yW7cxd8DYQ=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"yargs": {
"version": "1.3.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/yargs/-/yargs-1.3.3.tgz",
"integrity": "sha1-BU3oth8i7v23IHBZ6u+da4P7kxo=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"colors": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/colors/-/colors-1.1.2.tgz",
"integrity": "sha1-FopHAXVran9RoSzgyXv6KMCE7WM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"combined-stream": {
"version": "1.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/combined-stream/-/combined-stream-1.0.5.tgz",
"integrity": "sha1-k4NwpXtKUd6ix3wV1cX9+JUWQAk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"commander": {
"version": "2.9.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/commander/-/commander-2.9.0.tgz",
"integrity": "sha1-nJkJQXbhIkDLItbFFGCYQA/g99Q=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"concat-map": {
"version": "0.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/concat-map/-/concat-map-0.0.1.tgz",
"integrity": "sha1-2Klr13/Wjfd5OnMDajug1UBdR3s=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"concat-stream": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.6.0",
"resolved": "https://registry.npmjs.org/concat-stream/-/concat-stream-1.6.0.tgz",
"integrity": "sha1-CqxmL9Ur54lk1VMvaUeE5wEQrPc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"console-browserify": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/console-browserify/-/console-browserify-1.1.0.tgz",
"integrity": "sha1-8CQcRXMKn8YyOyBtvzjtx0HQuxA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"content-type": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/content-type/-/content-type-1.0.2.tgz",
"integrity": "sha1-t9ETrueo3Se9IRM8TcJSnfFyHu0=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"core-util-is": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz",
"integrity": "sha1-tf1UIgqivFq1eqtxQMlAdUUDwac=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"cosmiconfig": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.1.3",
"resolved": "https://registry.npmjs.org/cosmiconfig/-/cosmiconfig-2.1.3.tgz",
"integrity": "sha1-lSdx6w3dwcs/ovb75RpSLpOz7go=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"minimist": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.0.tgz",
"integrity": "sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"cpr": {
"version": "0.0.6",
"resolved": "https://registry.npmjs.org/cpr/-/cpr-0.0.6.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-U43SYnolrlDtoNwPgyKfuWDQhrM=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"graceful-fs": {
"version": "1.1.14",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-1.1.14.tgz",
"integrity": "sha1-BweNtfY3f2Mh/Oqu30l94STclGU=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"mkdirp": {
"version": "0.3.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.5.tgz",
"integrity": "sha1-3j5fiWHIjHh+4TaN+EmsRBPsqNc=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
"rimraf": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"version": "2.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/rimraf/-/rimraf-2.0.3.tgz",
"integrity": "sha1-9QopZecUTpr9mYmC8V33BnMPVqk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"cryptiles": {
"version": "2.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/cryptiles/-/cryptiles-2.0.5.tgz",
"integrity": "sha1-O9/s3GCBR8HGcgL6KR59ylnqo7g=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"css-color-names": {
"version": "0.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/css-color-names/-/css-color-names-0.0.3.tgz",
"integrity": "sha1-3gzvFvTYqoIioyDVttfpu62nufY=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"css-rule-stream": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/css-rule-stream/-/css-rule-stream-1.1.0.tgz",
"integrity": "sha1-N4bnGYmD2WWibjGVfgkHjLt3BaI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"css-tokenize": {
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/css-tokenize/-/css-tokenize-1.0.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-RiXLHtohwUOFi3+B1oA8HSb8FL4=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"isarray": {
"version": "0.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz",
"integrity": "sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"readable-stream": {
"version": "1.1.14",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.1.14.tgz",
"integrity": "sha1-fPTFTvZI44EwhMY23SB54WbAgdk=",
"dev": true
},
"string_decoder": {
"version": "0.10.31",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz",
"integrity": "sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"csslint": {
"version": "0.10.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/csslint/-/csslint-0.10.0.tgz",
"integrity": "sha1-OmoE51Zcjp0ZvrSXZ8fslug2WAU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"cssproc": {
"version": "0.0.7",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/cssproc/-/cssproc-0.0.7.tgz",
"integrity": "sha1-+Ch4pPhKvpcxVUK5ln9mUNhdPf4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"currently-unhandled": {
"version": "0.4.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/currently-unhandled/-/currently-unhandled-0.4.1.tgz",
"integrity": "sha1-mI3zP+qxke95mmE2nddsF635V+o=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"d": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/d/-/d-1.0.0.tgz",
"integrity": "sha1-dUu1v+VUUdpppYuU1F9MWwRi1Y8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dashdash": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.14.1",
"resolved": "https://registry.npmjs.org/dashdash/-/dashdash-1.14.1.tgz",
"integrity": "sha1-hTz6D3y+L+1d4gMmuN1YEDX24vA=",
"dev": true,
"optional": true,
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"dependencies": {
"assert-plus": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz",
"integrity": "sha1-8S4PPF13sLHN2RRpQuTpbB5N1SU=",
"dev": true,
"optional": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"date-now": {
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/date-now/-/date-now-0.1.4.tgz",
"integrity": "sha1-6vQ5/U1ISK105cx9vvIAZyueNFs=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"dateformat": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.12",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/dateformat/-/dateformat-1.0.12.tgz",
"integrity": "sha1-nxJLZ1lMk3/3BpMuSmQsyo27/uk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"debug": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.6.8",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.6.8.tgz",
"integrity": "sha1-5zFTHKLt4n0YgiJCfaF4IdaP9Pw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"decamelize": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/decamelize/-/decamelize-1.2.0.tgz",
"integrity": "sha1-9lNNFRSCabIDUue+4m9QH5oZEpA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"deep-is": {
"version": "0.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/deep-is/-/deep-is-0.1.3.tgz",
"integrity": "sha1-s2nW+128E+7PUk+RsHD+7cNXzzQ=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"del": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "2.2.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/del/-/del-2.2.2.tgz",
"integrity": "sha1-wSyYHQZ4RshLyvhiz/kw2Qf/0ag=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"delayed-stream": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/delayed-stream/-/delayed-stream-1.0.0.tgz",
"integrity": "sha1-3zrhmayt+31ECqrgsp4icrJOxhk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"depd": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/depd/-/depd-1.1.0.tgz",
"integrity": "sha1-4b2Cxqq2ztlluXuIsX7T5SjKGMM=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"doctrine": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.5.0",
"resolved": "https://registry.npmjs.org/doctrine/-/doctrine-1.5.0.tgz",
"integrity": "sha1-N53Ocw9hZvds76TmcHoVmwLFpvo=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"doiuse": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.6.0",
"resolved": "https://registry.npmjs.org/doiuse/-/doiuse-2.6.0.tgz",
"integrity": "sha1-GJLRC2Gpo1at2/K2FJM+gfi7ODQ=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"source-map": {
"version": "0.4.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.4.4.tgz",
"integrity": "sha1-66T12pwNyZneaAMti092FzZSA2s=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dom-serializer": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/dom-serializer/-/dom-serializer-0.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-BzxpdUbOB4DOI75KKOKT5AvDDII=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"domelementtype": {
"version": "1.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-1.1.3.tgz",
"integrity": "sha1-vSh3PiZCiBrsUVRJJCmcXNgiGFs=",
"dev": true
},
"entities": {
"version": "1.1.1",
"resolved": "https://registry.npmjs.org/entities/-/entities-1.1.1.tgz",
"integrity": "sha1-blwtClYhtdra7O+AuQ7ftc13cvA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"domelementtype": {
"version": "1.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/domelementtype/-/domelementtype-1.3.0.tgz",
"integrity": "sha1-sXrtguirWeUt2cGbF1bg/BhyBMI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"domhandler": {
"version": "2.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/domhandler/-/domhandler-2.3.0.tgz",
"integrity": "sha1-LeWaCCLVAn+r/28DLCsloqir5zg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"domutils": {
"version": "1.5.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/domutils/-/domutils-1.5.1.tgz",
"integrity": "sha1-3NhIiib1Y9YQeeSMn3t+Mjc2gs8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"duplexer": {
"version": "0.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/duplexer/-/duplexer-0.1.1.tgz",
"integrity": "sha1-rOb/gIwc5mtX0ev5eXessCM0z8E=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"duplexer2": {
"version": "0.0.2",
"resolved": "https://registry.npmjs.org/duplexer2/-/duplexer2-0.0.2.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-xhTc9n4vsUmVqRcR5aYX6KYKMds=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"isarray": {
"version": "0.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz",
"integrity": "sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"readable-stream": {
"version": "1.1.14",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.1.14.tgz",
"integrity": "sha1-fPTFTvZI44EwhMY23SB54WbAgdk=",
"dev": true
},
"string_decoder": {
"version": "0.10.31",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz",
"integrity": "sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"ecc-jsbn": {
"version": "0.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ecc-jsbn/-/ecc-jsbn-0.1.1.tgz",
"integrity": "sha1-D8c6ntXw1Tw4GTOYUj735UN3dQU=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"ee-first": {
"version": "1.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ee-first/-/ee-first-1.1.1.tgz",
"integrity": "sha1-WQxhFWsK4vTwJVcyoViyZrxWsh0=",
"dev": true
},
"electron-to-chromium": {
"version": "1.3.13",
"resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.3.13.tgz",
"integrity": "sha1-GzperObgh7teJXoQCwy/6Bsokfw=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"entities": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/entities/-/entities-1.0.0.tgz",
"integrity": "sha1-sph6o4ITR/zeZCsk/fyeT7cSvyY=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"errno": {
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/errno/-/errno-0.1.4.tgz",
"integrity": "sha1-uJbiOp5ei6M4cfyZar02NfyaHH0=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"error-ex": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/error-ex/-/error-ex-1.3.1.tgz",
"integrity": "sha1-+FWobOYa3E6GIcPNoh56dhLDqNw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"es5-ext": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.10.21",
"resolved": "https://registry.npmjs.org/es5-ext/-/es5-ext-0.10.21.tgz",
"integrity": "sha1-Gacl+eUdAwC7wejoIRCf2dr1WSU=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"es6-iterator": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.1",
"resolved": "https://registry.npmjs.org/es6-iterator/-/es6-iterator-2.0.1.tgz",
"integrity": "sha1-jjGcnwRTv1ddN0lAplWSDlnKVRI=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"es6-map": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.1.5",
"resolved": "https://registry.npmjs.org/es6-map/-/es6-map-0.1.5.tgz",
"integrity": "sha1-kTbgUD3MBqMBaQ8LsU/042TpSfA=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"es6-set": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.1.5",
"resolved": "https://registry.npmjs.org/es6-set/-/es6-set-0.1.5.tgz",
"integrity": "sha1-0rPsXU2ADO2BjbU40ol02wpzzLE=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"es6-symbol": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.1.1",
"resolved": "https://registry.npmjs.org/es6-symbol/-/es6-symbol-3.1.1.tgz",
"integrity": "sha1-vwDvT9q2uhtG7Le2KbTH7VcVzHc=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"es6-weak-map": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.2",
"resolved": "https://registry.npmjs.org/es6-weak-map/-/es6-weak-map-2.0.2.tgz",
"integrity": "sha1-XjqzIlH/0VOKH45f+hNXdy+S2W8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"escape-string-regexp": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-1.0.5.tgz",
"integrity": "sha1-G2HAViGQqN/2rjuyzwIAyhMLhtQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"escodegen": {
"version": "0.0.28",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/escodegen/-/escodegen-0.0.28.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-Dk/xcV8yh3XWyrUaxEpAbNer/9M=",
"dev": true,
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"dependencies": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"esprima": {
"version": "1.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/esprima/-/esprima-1.0.4.tgz",
"integrity": "sha1-n1V+CPw7TSbs6d00+Pv0drYlha0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"estraverse": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.3.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-1.3.2.tgz",
"integrity": "sha1-N8K4k+8T1yPydth41g2FNRUqbEI=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
}
}
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"escope": {
"version": "3.6.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/escope/-/escope-3.6.0.tgz",
"integrity": "sha1-4Bl16BJ4GhY6ba392AOY3GTIicM=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"eslint": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "3.7.1",
"resolved": "https://registry.npmjs.org/eslint/-/eslint-3.7.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-f6qEWZ4P6kIvBLwy20kFQFGj8Ro=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-57139 eslint: enable eslint-plugin-promise rules For promise best practices
2016-12-16 10:13:25 +00:00
"eslint-plugin-promise": {
"version": "3.5.0",
"resolved": "https://registry.npmjs.org/eslint-plugin-promise/-/eslint-plugin-promise-3.5.0.tgz",
"integrity": "sha1-ePu2/+BHIBYnVp6FpsU3OvKmj8o=",
"dev": true
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"espree": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.4.3",
"resolved": "https://registry.npmjs.org/espree/-/espree-3.4.3.tgz",
"integrity": "sha1-KRC1zNSc6JPC//+qtP2LOjG4I3Q=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"esprima": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.1.3",
"resolved": "https://registry.npmjs.org/esprima/-/esprima-3.1.3.tgz",
"integrity": "sha1-/cpRzuYTOJXjyI1TXOSdv/YqRjM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"esrecurse": {
"version": "4.1.0",
"resolved": "https://registry.npmjs.org/esrecurse/-/esrecurse-4.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-RxO2U2rffyrE8yfVWed1a/9kgiA=",
"dev": true,
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"dependencies": {
"estraverse": {
"version": "4.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-4.1.1.tgz",
"integrity": "sha1-9srKcokzqFDvkGYdDheYK6RxEaI=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"estraverse": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "4.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/estraverse/-/estraverse-4.2.0.tgz",
"integrity": "sha1-De4/7TH81GlhjOc0IJn8GvoL2xM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"esutils": {
"version": "2.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/esutils/-/esutils-2.0.2.tgz",
"integrity": "sha1-Cr9PHKpbyx96nYrMbepPqqBLrJs=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"event-emitter": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.3.5",
"resolved": "https://registry.npmjs.org/event-emitter/-/event-emitter-0.3.5.tgz",
"integrity": "sha1-34xp7vFkeSPHFXuc6DhAYQsCzDk=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"eventemitter2": {
"version": "0.4.14",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/eventemitter2/-/eventemitter2-0.4.14.tgz",
"integrity": "sha1-j2G3XN4BKy6esoTUVFWDtWQ7Yas=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"execall": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/execall/-/execall-1.0.0.tgz",
"integrity": "sha1-c9CQTjlbPKsGWLCNCewlMH8pu3M=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"exit": {
"version": "0.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/exit/-/exit-0.1.2.tgz",
"integrity": "sha1-BjJjj42HfMghB9MKD/8aF8uhzQw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"exit-hook": {
"version": "1.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/exit-hook/-/exit-hook-1.1.1.tgz",
"integrity": "sha1-8FyiM7SMBdVP/wd2XfhQfpXAL/g=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"extend": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/extend/-/extend-3.0.1.tgz",
"integrity": "sha1-p1Xqe8Gt/MWjHOfnYtuq3F5jZEQ=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"extsprintf": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/extsprintf/-/extsprintf-1.0.2.tgz",
"integrity": "sha1-4QgOBljjALBilJkMxw4VAiNf1VA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"fast-levenshtein": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.6",
"resolved": "https://registry.npmjs.org/fast-levenshtein/-/fast-levenshtein-2.0.6.tgz",
"integrity": "sha1-PYpcZog6FqMMqGQ+hR8Zuqd5eRc=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"faye-websocket": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.10.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/faye-websocket/-/faye-websocket-0.10.0.tgz",
"integrity": "sha1-TkkvjQTftviQA1B/btvy1QHnxvQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"figures": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.7.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/figures/-/figures-1.7.0.tgz",
"integrity": "sha1-y+Hjr/zxzUS4DK3+0o3Hk6lwHS4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"file-entry-cache": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/file-entry-cache/-/file-entry-cache-2.0.0.tgz",
"integrity": "sha1-w5KZDD5oR4PYOLjISkXYoEhFg2E=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"fileset": {
"version": "0.1.8",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/fileset/-/fileset-0.1.8.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-UGuRqTluqn4y+0KoQHfHoMc2t0E=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"glob": {
"version": "3.2.11",
"resolved": "https://registry.npmjs.org/glob/-/glob-3.2.11.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-Spc/Y1uRkPcV0QmH1cAP0oFevj0=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"minimatch": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.3.0.tgz",
"integrity": "sha1-J12O2qxPG7MyZHIInnlJyDlGmd0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
"minimatch": {
"version": "0.4.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.4.0.tgz",
"integrity": "sha1-vSx9Bg0sjI/Xzefx8u0tWycP2xs=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"find-up": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/find-up/-/find-up-1.1.2.tgz",
"integrity": "sha1-ay6YIrGizgpgq2TWEOzK1TyyTQ8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"findup-sync": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.3.0",
"resolved": "https://registry.npmjs.org/findup-sync/-/findup-sync-0.3.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-N5MKpdgWt3fANEXhlmzGeQpMCxY=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"glob": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "5.0.15",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/glob/-/glob-5.0.15.tgz",
"integrity": "sha1-G8k2ueAvSmA/zCIuz3Yz0wuLk7E=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"flat-cache": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.2.2",
"resolved": "https://registry.npmjs.org/flat-cache/-/flat-cache-1.2.2.tgz",
"integrity": "sha1-+oZxTnLCHbiGAXYezy9VXRq8a5Y=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"flatten": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/flatten/-/flatten-1.0.2.tgz",
"integrity": "sha1-2uRqnXj74lKSJYzB54CkHZXAN4I=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"forever-agent": {
"version": "0.6.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/forever-agent/-/forever-agent-0.6.1.tgz",
"integrity": "sha1-+8cfDEGt6zf5bFd60e1C2P2sypE=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"form-data": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.1.4",
"resolved": "https://registry.npmjs.org/form-data/-/form-data-2.1.4.tgz",
"integrity": "sha1-M8GDrPGTJ27KqYFDpp6Uv+4XUNE=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-54944 eslint: Add rules from Policy decision Also bump eslint to v2.13.1 and make the version explicit in package.json
2016-06-28 21:03:27 +01:00
"fs.realpath": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/fs.realpath/-/fs.realpath-1.0.0.tgz",
"integrity": "sha1-FQStJSMVjKpA20onh8sBQRmU6k8=",
"dev": true
MDL-54944 eslint: Add rules from Policy decision Also bump eslint to v2.13.1 and make the version explicit in package.json
2016-06-28 21:03:27 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"gather-stream": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/gather-stream/-/gather-stream-1.0.0.tgz",
"integrity": "sha1-szmUr0V6gRVwDUEPMXczy+egkEs=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"gaze": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/gaze/-/gaze-1.1.2.tgz",
"integrity": "sha1-hHIkZ3rbiHDWeSV+0ziP22HkAQU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"gear": {
"version": "0.8.18",
"resolved": "https://registry.npmjs.org/gear/-/gear-0.8.18.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-JVft8B/2FFNYrfyoyBonzuik3Do=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"async": {
"version": "0.2.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-0.2.10.tgz",
"integrity": "sha1-trvgsGdLnXGXCMo43owjfLUmw9E=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"mkdirp": {
"version": "0.3.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.5.tgz",
"integrity": "sha1-3j5fiWHIjHh+4TaN+EmsRBPsqNc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"gear-lib": {
"version": "0.8.15",
"resolved": "https://registry.npmjs.org/gear-lib/-/gear-lib-0.8.15.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-/AdqFOd5Yzab7XUraURqbtz2CW4=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"async": {
"version": "0.2.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-0.2.10.tgz",
"integrity": "sha1-trvgsGdLnXGXCMo43owjfLUmw9E=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"glob": {
"version": "3.2.11",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/glob/-/glob-3.2.11.tgz",
"integrity": "sha1-Spc/Y1uRkPcV0QmH1cAP0oFevj0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"jshint": {
"version": "2.5.11",
"resolved": "https://registry.npmjs.org/jshint/-/jshint-2.5.11.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-4tlYWLuxqngwAQii6BCZ+wlWIuA=",
"dev": true,
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
"dependencies": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"minimatch": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-1.0.0.tgz",
"integrity": "sha1-4N0hILSeG3JM6NcUxSCCKpQ4V20=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"less": {
"version": "1.3.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/less/-/less-1.3.3.tgz",
"integrity": "sha1-fujzAKQQgPNUTIDHpwzfamEoDPk=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"mime": {
"version": "1.2.11",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mime/-/mime-1.2.11.tgz",
"integrity": "sha1-WCA+7Ybjpe8XrtK32evUfwpg3RA=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"minimatch": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.3.0.tgz",
"integrity": "sha1-J12O2qxPG7MyZHIInnlJyDlGmd0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"shelljs": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/shelljs/-/shelljs-0.3.0.tgz",
"integrity": "sha1-NZbmMHp4FUT1kfN9phg2DzHbV7E=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"uglify-js": {
"version": "1.3.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-1.3.5.tgz",
"integrity": "sha1-S1v/+Rhu/7qoiOTJ6UvZ/EyUkp0=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"generate-function": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/generate-function/-/generate-function-2.0.0.tgz",
"integrity": "sha1-aFj+fAlpt9TpCTM3ZHrHn2DfvnQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"generate-object-property": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/generate-object-property/-/generate-object-property-1.2.0.tgz",
"integrity": "sha1-nA4cQDCM6AT0eDYYuTf6iPmdUNA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"get-stdin": {
"version": "4.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-4.0.1.tgz",
"integrity": "sha1-uWjGsKBDhDJJAui/Gl3zJXmkUP4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"getobject": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/getobject/-/getobject-0.1.0.tgz",
"integrity": "sha1-BHpEl4n6Fg0Bj1SG7ZEyC27HiFw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"getpass": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.1.7",
"resolved": "https://registry.npmjs.org/getpass/-/getpass-0.1.7.tgz",
"integrity": "sha1-Xv+OPmhNVprkyysSgmBOi6YhSfo=",
"dev": true,
"optional": true,
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"dependencies": {
"assert-plus": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz",
"integrity": "sha1-8S4PPF13sLHN2RRpQuTpbB5N1SU=",
"dev": true,
"optional": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
}
}
},
MDL-56519 behat: Lint gherkin files
2016-10-20 10:53:05 +01:00
"gherkin": {
"version": "4.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/gherkin/-/gherkin-4.0.0.tgz",
"integrity": "sha1-edzgTRIj6kO0hip2vlzo+JwSwyw=",
"dev": true
MDL-56519 behat: Lint gherkin files
2016-10-20 10:53:05 +01:00
},
"gherkin-lint": {
"version": "1.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/gherkin-lint/-/gherkin-lint-1.1.3.tgz",
"integrity": "sha1-7V5s3S+VSsJle1tCCBBGk+gqoho=",
"dev": true,
"dependencies": {
"glob": {
"version": "7.0.5",
"resolved": "https://registry.npmjs.org/glob/-/glob-7.0.5.tgz",
"integrity": "sha1-tCAqaQmbu00pKnwblbZoK2fr3JU=",
"dev": true
},
"lodash": {
"version": "4.13.1",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.13.1.tgz",
"integrity": "sha1-g+SxCRP0hJbU0W/sSlYK8u50S2g=",
"dev": true
}
}
MDL-56519 behat: Lint gherkin files
2016-10-20 10:53:05 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"glob": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "7.1.2",
"resolved": "https://registry.npmjs.org/glob/-/glob-7.1.2.tgz",
"integrity": "sha512-MJTUg1kjuLeQCJ+ccE4Vpa6kKVXkPYJ2mOCQyUuKLcLQsdrMCpBPUi8qVE6+YuaJkozeA9NusTAw3hLr8Xe5EQ==",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"globals": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "9.17.0",
"resolved": "https://registry.npmjs.org/globals/-/globals-9.17.0.tgz",
"integrity": "sha1-DAymltm5u2lNLlRwvTd3fKrVAoY=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"globby": {
MDL-54944 eslint: Add rules from Policy decision Also bump eslint to v2.13.1 and make the version explicit in package.json
2016-06-28 21:03:27 +01:00
"version": "5.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/globby/-/globby-5.0.0.tgz",
"integrity": "sha1-69hGZ8oNuzMLmbz8aOrCvFQ3Dg0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"globjoin": {
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/globjoin/-/globjoin-0.1.4.tgz",
"integrity": "sha1-L0SUrIkZ43Z8XLtpHp9GMyQoXUM=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"globule": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/globule/-/globule-1.1.0.tgz",
"integrity": "sha1-xJNS5NwYPYWJPuglOF65lLtt9F8=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"lodash": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.16.6",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.16.6.tgz",
"integrity": "sha1-0iyaxmAojzhD4Wun0rXQbMon13c=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"graceful-fs": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.1.11",
"resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.1.11.tgz",
"integrity": "sha1-Dovf5NHduIVNZOBOp8AOKgJuVlg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"graceful-readlink": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/graceful-readlink/-/graceful-readlink-1.0.1.tgz",
"integrity": "sha1-TK+tdrxi8C+gObL5Tpo906ORpyU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"grunt": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/grunt/-/grunt-1.0.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-6HeHZOlEsY8yuw8QuQeEdcnftWs=",
"dev": true,
MDL-49817 grunt: handle multiple watched files changed at once 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!)
2016-01-21 14:21:13 +00:00
"dependencies": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"esprima": {
"version": "2.7.3",
"resolved": "https://registry.npmjs.org/esprima/-/esprima-2.7.3.tgz",
"integrity": "sha1-luO3DVd59q1JzQMmc9HDEnZ7pYE=",
"dev": true
},
"glob": {
"version": "7.0.6",
"resolved": "https://registry.npmjs.org/glob/-/glob-7.0.6.tgz",
"integrity": "sha1-IRuvr0nlJbjNkyYNFKsTYVKz9Xo=",
"dev": true
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"grunt-cli": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-cli/-/grunt-cli-1.2.0.tgz",
"integrity": "sha1-VisRnrsGndtGSs4oRVAb6Xs1tqg=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"js-yaml": {
"version": "3.5.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.5.5.tgz",
"integrity": "sha1-A3fDgBfKvHMisNH7zSWkkWQfL74=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"rimraf": {
"version": "2.2.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/rimraf/-/rimraf-2.2.8.tgz",
"integrity": "sha1-5Dm+Kq7jJzIZUnMPmaiSnk/FBYI=",
"dev": true
MDL-49817 grunt: handle multiple watched files changed at once 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!)
2016-01-21 14:21:13 +00:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
"grunt-contrib-less": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-contrib-less/-/grunt-contrib-less-1.3.0.tgz",
"integrity": "sha1-UY73yG3GDhWeZRCKp125OpyP9dQ=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
"grunt-contrib-uglify": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-contrib-uglify/-/grunt-contrib-uglify-1.0.1.tgz",
"integrity": "sha1-rWhBG5Y7mWYSEfdvRmve3tT7B6w=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"grunt-contrib-watch": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.0",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/grunt-contrib-watch/-/grunt-contrib-watch-1.0.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-hKGnodar0m7VaEE0lscxM+mQAY8=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"lodash": {
"version": "3.10.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lodash/-/lodash-3.10.1.tgz",
"integrity": "sha1-W/Rejkm6QYnhfUgnid/RW9FAt7Y=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"grunt-eslint": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "19.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-eslint/-/grunt-eslint-19.0.0.tgz",
"integrity": "sha1-u3TDeQYVmc7B9mFp3vKonYYthhs=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
"grunt-known-options": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-known-options/-/grunt-known-options-1.1.0.tgz",
"integrity": "sha1-pCdO6zL6dl2lp6OxcSYXzjsUQUk=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"grunt-legacy-log": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.0",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/grunt-legacy-log/-/grunt-legacy-log-1.0.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-+4bxgJhHvAfcR4Q/ns1srLYt8tU=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"lodash": {
"version": "3.10.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lodash/-/lodash-3.10.1.tgz",
"integrity": "sha1-W/Rejkm6QYnhfUgnid/RW9FAt7Y=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"grunt-legacy-log-utils": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/grunt-legacy-log-utils/-/grunt-legacy-log-utils-1.0.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-p7ji0Ps1taUPSvmG/BEnSevJbz0=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"lodash": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "4.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.3.0.tgz",
"integrity": "sha1-79nEpuxT87BUEkKZFcPkgk5NJaQ=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"grunt-legacy-util": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/grunt-legacy-util/-/grunt-legacy-util-1.0.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-OGqnjcbtUJhsKxiVcmWxtIq7m4Y=",
"dev": true,
MDL-49817 grunt: handle multiple watched files changed at once 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!)
2016-01-21 14:21:13 +00:00
"dependencies": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"lodash": {
"version": "4.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.3.0.tgz",
"integrity": "sha1-79nEpuxT87BUEkKZFcPkgk5NJaQ=",
"dev": true
MDL-49817 grunt: handle multiple watched files changed at once 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!)
2016-01-21 14:21:13 +00:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"grunt-stylelint": {
"version": "0.6.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/grunt-stylelint/-/grunt-stylelint-0.6.0.tgz",
"integrity": "sha1-Wt2fZeEWA+ShmEGNvtFmqpuPRpk=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"gzip-size": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/gzip-size/-/gzip-size-1.0.0.tgz",
"integrity": "sha1-Zs+LEBBHInuVus5uodoMF37Vwi8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"handlebars": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/handlebars/-/handlebars-2.0.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-bp1/hRSjRn+l6fgswVjs/B1ax28=",
"dev": true,
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
"dependencies": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"async": {
"version": "0.2.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-0.2.10.tgz",
"integrity": "sha1-trvgsGdLnXGXCMo43owjfLUmw9E=",
"dev": true,
"optional": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"source-map": {
"version": "0.1.43",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.1.43.tgz",
"integrity": "sha1-wkvBRspRfBRx9drL4lcbK3+eM0Y=",
"dev": true,
"optional": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"uglify-js": {
"version": "2.3.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.3.6.tgz",
"integrity": "sha1-+gmEdwtCi3qbKoBY9GNV0U/vIRo=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"har-schema": {
"version": "1.0.5",
"resolved": "https://registry.npmjs.org/har-schema/-/har-schema-1.0.5.tgz",
"integrity": "sha1-0mMTX0MwfALGAq/I/pWXDAFRNp4=",
"dev": true,
"optional": true
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"har-validator": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.2.1",
"resolved": "https://registry.npmjs.org/har-validator/-/har-validator-4.2.1.tgz",
"integrity": "sha1-M0gdDxu/9gDdID11gSpqX7oALio=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"has-ansi": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/has-ansi/-/has-ansi-2.0.0.tgz",
"integrity": "sha1-NPUEnOHs3ysGSa8+8k5F7TVBbZE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"has-flag": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/has-flag/-/has-flag-1.0.0.tgz",
"integrity": "sha1-nZ55MWXOAXoA8AQYxD+UKnsdEfo=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"hawk": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "3.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/hawk/-/hawk-3.1.3.tgz",
"integrity": "sha1-B4REvXwWQLD+VA0sm3PVlnjo4cQ=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"hoek": {
"version": "2.16.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/hoek/-/hoek-2.16.3.tgz",
"integrity": "sha1-ILt0A9POo5jpHcRxCo/xuCdKJe0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"hooker": {
"version": "0.2.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/hooker/-/hooker-0.2.3.tgz",
"integrity": "sha1-uDT3I8xKJCqmWWNFnfbZhMXT2Vk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"hosted-git-info": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.4.2",
"resolved": "https://registry.npmjs.org/hosted-git-info/-/hosted-git-info-2.4.2.tgz",
"integrity": "sha1-AHa59GonBQbduq6lZJaJdGBhKmc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"html-tags": {
"version": "1.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/html-tags/-/html-tags-1.1.1.tgz",
"integrity": "sha1-hp9DhZ8S2b3DiSQZ5JSmKKobIE4=",
"dev": true
},
"htmlparser2": {
"version": "3.8.3",
"resolved": "https://registry.npmjs.org/htmlparser2/-/htmlparser2-3.8.3.tgz",
"integrity": "sha1-mWwosZFRaovoZQGn15dX5ccMEGg=",
"dev": true,
"dependencies": {
"isarray": {
"version": "0.0.1",
"resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz",
"integrity": "sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=",
"dev": true
},
"readable-stream": {
"version": "1.1.14",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.1.14.tgz",
"integrity": "sha1-fPTFTvZI44EwhMY23SB54WbAgdk=",
"dev": true
},
"string_decoder": {
"version": "0.10.31",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz",
"integrity": "sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=",
"dev": true
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"http-errors": {
"version": "1.3.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/http-errors/-/http-errors-1.3.1.tgz",
"integrity": "sha1-GX4izevUGYWF6GlO9nhhl7ke2UI=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"http-signature": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/http-signature/-/http-signature-1.1.1.tgz",
"integrity": "sha1-33LiZwZs0Kxn+3at+OE0qPvPkb8=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"iconv-lite": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.4.17",
"resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.17.tgz",
"integrity": "sha1-T9qjs4rLwsAxsEXQ7c3+HsqxjI0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"ignore": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.3.3",
"resolved": "https://registry.npmjs.org/ignore/-/ignore-3.3.3.tgz",
"integrity": "sha1-QyNS5XrM2HqzEQ6C0/6g5HgSFW0=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"image-size": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.4.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/image-size/-/image-size-0.4.0.tgz",
"integrity": "sha1-1LTh9hlS5MvBzqmmsMkV/stwdRA=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"imurmurhash": {
"version": "0.1.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/imurmurhash/-/imurmurhash-0.1.4.tgz",
"integrity": "sha1-khi5srkoojixPcT7a21XbyMUU+o=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"indent-string": {
"version": "2.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/indent-string/-/indent-string-2.1.0.tgz",
"integrity": "sha1-ji1INIdCEhtKghi3oTfppSBJ3IA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"indexes-of": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/indexes-of/-/indexes-of-1.0.1.tgz",
"integrity": "sha1-8w9xbI4r00bHtn0985FVZqfAVgc=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"inflight": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.6",
"resolved": "https://registry.npmjs.org/inflight/-/inflight-1.0.6.tgz",
"integrity": "sha1-Sb1jMdfQLQwJvJEKEHW6gWW1bfk=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"inherits": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.3",
"resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.3.tgz",
"integrity": "sha1-Yzwsg+PaQqUC9SRmAiSA9CCCYd4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"inquirer": {
"version": "0.12.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/inquirer/-/inquirer-0.12.0.tgz",
"integrity": "sha1-HvK/1jUE3wvHV4X/+MLEHfEvB34=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"irregular-plurals": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/irregular-plurals/-/irregular-plurals-1.2.0.tgz",
"integrity": "sha1-OPKZg0uowAwwvpxVThNyaXUv86w=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"is-arrayish": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-arrayish/-/is-arrayish-0.2.1.tgz",
"integrity": "sha1-d8mYQFJ6qOyxqLppe4BkWnqSap0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"is-buffer": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.1.5",
"resolved": "https://registry.npmjs.org/is-buffer/-/is-buffer-1.1.5.tgz",
"integrity": "sha1-Hzsm72E7IUuIy8ojzGwB2Hlh7sw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"is-builtin-module": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-builtin-module/-/is-builtin-module-1.0.0.tgz",
"integrity": "sha1-VAVy0096wxGfj3bDDLwbHgN6/74=",
"dev": true
},
"is-directory": {
"version": "0.3.1",
"resolved": "https://registry.npmjs.org/is-directory/-/is-directory-0.3.1.tgz",
"integrity": "sha1-YTObbyR1/Hcv2cnYP1yFddwVSuE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"is-finite": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/is-finite/-/is-finite-1.0.2.tgz",
"integrity": "sha1-zGZ3aVYCvlUO8R6LSqYwU0K20Ko=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"is-fullwidth-code-point": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-1.0.0.tgz",
"integrity": "sha1-754xOG8DGn8NZDr4L95QxFfvAMs=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"is-my-json-valid": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.16.0",
"resolved": "https://registry.npmjs.org/is-my-json-valid/-/is-my-json-valid-2.16.0.tgz",
"integrity": "sha1-8Hndm/2uZe4gOKrorLyGqxCeNpM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"is-path-cwd": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-path-cwd/-/is-path-cwd-1.0.0.tgz",
"integrity": "sha1-0iXsIxMuie3Tj9p2dHLmLmXxEG0=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"is-path-in-cwd": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-path-in-cwd/-/is-path-in-cwd-1.0.0.tgz",
"integrity": "sha1-ZHdYK4IU1gI0YJRWcAO+ip6sBNw=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"is-path-inside": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-path-inside/-/is-path-inside-1.0.0.tgz",
"integrity": "sha1-/AbloWg/vaE95mev9xe7wQpI838=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"is-property": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-property/-/is-property-1.0.2.tgz",
"integrity": "sha1-V/4cTkhHTt1lsJkR8msc1Ald2oQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"is-regexp": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-regexp/-/is-regexp-1.0.0.tgz",
"integrity": "sha1-/S2INUXEa6xaYz57mgnof6LLUGk=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"is-resolvable": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-resolvable/-/is-resolvable-1.0.0.tgz",
"integrity": "sha1-jfV8YeouPFAUCNEA+wE8+NbgzGI=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"is-supported-regexp-flag": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-supported-regexp-flag/-/is-supported-regexp-flag-1.0.0.tgz",
"integrity": "sha1-i1IMhfrnolM4LUsCZS4EVXbhO7g=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"is-typedarray": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-typedarray/-/is-typedarray-1.0.0.tgz",
"integrity": "sha1-5HnICFjfDBsR3dppQPlgEfzaSpo=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"is-utf8": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-utf8/-/is-utf8-0.2.1.tgz",
"integrity": "sha1-Sw2hRCEE0bM2NA6AeX6GXPOffXI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"isarray": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isarray/-/isarray-1.0.0.tgz",
"integrity": "sha1-u5NdSFgsuhaMBoNJV6VKPgcSTxE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"isexe": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/isexe/-/isexe-2.0.0.tgz",
"integrity": "sha1-6PvzdNxVb/iUehDcsFctYz8s+hA=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"isstream": {
"version": "0.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isstream/-/isstream-0.1.2.tgz",
"integrity": "sha1-R+Y/evVa+m+S4VAOaQ64uFKcCZo=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"istanbul": {
"version": "0.1.37",
"resolved": "https://registry.npmjs.org/istanbul/-/istanbul-0.1.37.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-7ZwC4q+A2JRtQG1wFNkxk17y1+A=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"abbrev": {
"version": "1.0.9",
"resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.0.9.tgz",
"integrity": "sha1-kbR5JYinc4wl813W9jdSovh3YTU=",
"dev": true
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"async": {
"version": "0.2.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-0.2.10.tgz",
"integrity": "sha1-trvgsGdLnXGXCMo43owjfLUmw9E=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"esprima": {
"version": "1.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/esprima/-/esprima-1.0.4.tgz",
"integrity": "sha1-n1V+CPw7TSbs6d00+Pv0drYlha0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"handlebars": {
"version": "1.0.12",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/handlebars/-/handlebars-1.0.12.tgz",
"integrity": "sha1-GMbTRAw16RsZs/9YK5FRq0mF1Pw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"mkdirp": {
"version": "0.3.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.3.5.tgz",
"integrity": "sha1-3j5fiWHIjHh+4TaN+EmsRBPsqNc=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
"nopt": {
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"version": "2.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/nopt/-/nopt-2.1.2.tgz",
"integrity": "sha1-bMzZd7gBMqB3MdbozljCyDA8+a8=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolve": {
"version": "0.4.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/resolve/-/resolve-0.4.3.tgz",
"integrity": "sha1-3K2tIC58rMJGfjo4gAIR9C+cE98=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"source-map": {
"version": "0.1.43",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.1.43.tgz",
"integrity": "sha1-wkvBRspRfBRx9drL4lcbK3+eM0Y=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"uglify-js": {
"version": "2.3.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.3.6.tgz",
"integrity": "sha1-+gmEdwtCi3qbKoBY9GNV0U/vIRo=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"which": {
"version": "1.0.9",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/which/-/which-1.0.9.tgz",
"integrity": "sha1-RgwdoPgQED0DIam2M6+eV15kSG8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"wordwrap": {
"version": "0.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
"integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"jodid25519": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/jodid25519/-/jodid25519-1.0.2.tgz",
"integrity": "sha1-BtSRIlUJNBlHfUJWM2BuDpB4KWc=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"js-base64": {
"version": "2.1.9",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/js-base64/-/js-base64-2.1.9.tgz",
"integrity": "sha1-8OgK4DmkvWVLXygfyT8EqRSn/M4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"js-yaml": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.8.4",
"resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.8.4.tgz",
"integrity": "sha1-UgtFZPhlc7qWZir4Woyvp7S1pvY=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"jsbn": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.1.1",
"resolved": "https://registry.npmjs.org/jsbn/-/jsbn-0.1.1.tgz",
"integrity": "sha1-peZUwuWi3rXyAdls77yoDA7y9RM=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"jshint": {
"version": "0.9.1",
"resolved": "https://registry.npmjs.org/jshint/-/jshint-0.9.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-/zLsfwn4QAH3SY7q/WPJ5Puy3A4=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"cli": {
"version": "0.4.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/cli/-/cli-0.4.3.tgz",
"integrity": "sha1-5oGcjV+qlX9k+Y9mqFBiaMHR8X0=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"lru-cache": {
"version": "1.0.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-1.0.6.tgz",
"integrity": "sha1-qlD5cEdCKsclQ72hd6nJ0BjZhFI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"minimatch": {
"version": "0.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.0.5.tgz",
"integrity": "sha1-lrtJC707poNrv6wRGt91MBsVhN4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"jslint": {
"version": "0.3.4",
"resolved": "https://registry.npmjs.org/jslint/-/jslint-0.3.4.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-+3aKyN4GQfzFcMh8ofvSjik8jXU=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"glob": {
"version": "3.2.11",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/glob/-/glob-3.2.11.tgz",
"integrity": "sha1-Spc/Y1uRkPcV0QmH1cAP0oFevj0=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"minimatch": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-0.3.0.tgz",
"integrity": "sha1-J12O2qxPG7MyZHIInnlJyDlGmd0=",
"dev": true,
"optional": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"nopt": {
"version": "1.0.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/nopt/-/nopt-1.0.10.tgz",
"integrity": "sha1-bd0hvSoxQXuScn3Vhfim83YI6+4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"json-schema": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.2.3",
"resolved": "https://registry.npmjs.org/json-schema/-/json-schema-0.2.3.tgz",
"integrity": "sha1-tIDIkuWaLwWVTOcnvT8qTogvnhM=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"json-stable-stringify": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/json-stable-stringify/-/json-stable-stringify-1.0.1.tgz",
"integrity": "sha1-mnWdOcXy/1A/1TAGRu1EX4jE+a8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"json-stringify-safe": {
"version": "5.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/json-stringify-safe/-/json-stringify-safe-5.0.1.tgz",
"integrity": "sha1-Epai1Y/UXxmg9s4B1lcB4sc1tus=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"jsonfilter": {
"version": "1.1.2",
"resolved": "https://registry.npmjs.org/jsonfilter/-/jsonfilter-1.1.2.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-Ie987cdRk4E8dZMulqmL4gW6WhE=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"minimist": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.0.tgz",
"integrity": "sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"jsonify": {
"version": "0.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/jsonify/-/jsonify-0.0.0.tgz",
"integrity": "sha1-LHS27kHZPKUbe1qu6PUDYx0lKnM=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"jsonparse": {
"version": "0.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/jsonparse/-/jsonparse-0.0.5.tgz",
"integrity": "sha1-MwVCrT8KZUZlt3jz6y2an6UHrGQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"jsonpointer": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.0.1",
"resolved": "https://registry.npmjs.org/jsonpointer/-/jsonpointer-4.0.1.tgz",
"integrity": "sha1-T9kss04OnbPInIYi7PUfm5eMbLk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"JSONStream": {
"version": "0.8.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/JSONStream/-/JSONStream-0.8.4.tgz",
"integrity": "sha1-kWV9/m/4V0gwZhMrRhi2Lo9Ih70=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"jsprim": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/jsprim/-/jsprim-1.4.0.tgz",
"integrity": "sha1-o7h+QCmNjDgFUtjMdiigu5WiKRg=",
"dev": true,
"optional": true,
"dependencies": {
"assert-plus": {
"version": "1.0.0",
"resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz",
"integrity": "sha1-8S4PPF13sLHN2RRpQuTpbB5N1SU=",
"dev": true,
"optional": true
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"kind-of": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.2.2",
"resolved": "https://registry.npmjs.org/kind-of/-/kind-of-3.2.2.tgz",
"integrity": "sha1-MeohpzS6ubuw8yRm2JOupR5KPGQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"known-css-properties": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "0.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/known-css-properties/-/known-css-properties-0.0.5.tgz",
"integrity": "sha1-M95bgnkBCnLbkX0zEZ5MJ8B4SQo=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"knox": {
"version": "0.8.10",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/knox/-/knox-0.8.10.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-ai7c2sHSrjedHhmU1Vm5XCg7JYg=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"debug": {
"version": "0.7.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/debug/-/debug-0.7.4.tgz",
"integrity": "sha1-BuHqgILCyxTjmAbiLi9vdX+Srzk=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"lazy-cache": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lazy-cache/-/lazy-cache-1.0.4.tgz",
"integrity": "sha1-odePw6UEdMuAhF07O24dpJpEbo4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"ldjson-stream": {
"version": "1.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ldjson-stream/-/ldjson-stream-1.2.1.tgz",
"integrity": "sha1-kb7O2lrE7SsX5kn7d356v6AYnCs=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"less": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "2.6.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/less/-/less-2.6.1.tgz",
"integrity": "sha1-ZY4B7JrDFJlZxrbfvPvAoXCv2no=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"levn": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/levn/-/levn-0.3.0.tgz",
"integrity": "sha1-OwmSTt+fCDwEkP3UwLxEIeBHZO4=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"livereload-js": {
"version": "2.2.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/livereload-js/-/livereload-js-2.2.2.tgz",
"integrity": "sha1-bIclfmSKtHW8JOoldFftzB+NC8I=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"load-json-file": {
"version": "1.1.0",
"resolved": "https://registry.npmjs.org/load-json-file/-/load-json-file-1.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-lWkFcI1YtLq0wiYbBPWfMcmTdMA=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"strip-bom": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-2.0.0.tgz",
"integrity": "sha1-YhmoVhZSBJHzV4i9vxRHqZx+aw4=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"lodash": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.17.4",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.4.tgz",
"integrity": "sha1-eCA6TRwyiuHYbcpkYONptX9AVa4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"log-symbols": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/log-symbols/-/log-symbols-1.0.2.tgz",
"integrity": "sha1-N2/3tY6jCGoPCfrMdGF+ylAeGhg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"longest": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/longest/-/longest-1.0.1.tgz",
"integrity": "sha1-MKCy2jj3N3DoKUoNIuZiXtd9AJc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"loud-rejection": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.6.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/loud-rejection/-/loud-rejection-1.6.0.tgz",
"integrity": "sha1-W0b4AUft7leIcPCG0Eghz5mOVR8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"lru-cache": {
"version": "2.7.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-2.7.3.tgz",
"integrity": "sha1-bUUk6LlV+V1PW1iFHOId1y+06VI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"map-obj": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/map-obj/-/map-obj-1.0.1.tgz",
"integrity": "sha1-2TPOuSBdgr3PSIb2dCvcK03qFG0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"maxmin": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/maxmin/-/maxmin-1.1.0.tgz",
"integrity": "sha1-cTZehKmd2Piz99X94vANHn9zvmE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"media-typer": {
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/media-typer/-/media-typer-0.3.0.tgz",
"integrity": "sha1-hxDXrwqmJvj/+hzgAWhUUmMlV0g=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"meow": {
"version": "3.7.0",
"resolved": "https://registry.npmjs.org/meow/-/meow-3.7.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-cstmi0JSKCkKu/qFaJJYcwioAfs=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"minimist": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.0.tgz",
"integrity": "sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"mime": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.3.6",
"resolved": "https://registry.npmjs.org/mime/-/mime-1.3.6.tgz",
"integrity": "sha1-WR2E02U6awtKO5343lqoEI5y5eA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"mime-db": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.27.0",
"resolved": "https://registry.npmjs.org/mime-db/-/mime-db-1.27.0.tgz",
"integrity": "sha1-gg9XIpa70g7CXtVeW13oaeVDbrE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"mime-types": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.1.15",
"resolved": "https://registry.npmjs.org/mime-types/-/mime-types-2.1.15.tgz",
"integrity": "sha1-pOv1BkCUVpI3uM9wBGd20J/JKu0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"minimatch": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.0.4",
"resolved": "https://registry.npmjs.org/minimatch/-/minimatch-3.0.4.tgz",
"integrity": "sha512-yJHVQEhyqPLUTgt9B83PXu6W3rx4MvvHvSUvToogpwoGDOUQ+yDrR0HRot+yOCdCO7u4hX3pWft6kWBBcqh0UA==",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"minimist": {
"version": "0.0.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimist/-/minimist-0.0.8.tgz",
"integrity": "sha1-hX/Kv8M5fSYluCKCYuhqp6ARsF0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"mkdirp": {
"version": "0.5.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mkdirp/-/mkdirp-0.5.1.tgz",
"integrity": "sha1-MAV0OOrGz3+MR2fzhkjWaX11yQM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"ms": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/ms/-/ms-2.0.0.tgz",
"integrity": "sha1-VgiurfwAvmwpAd9fmGF4jeDVl8g=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"multimatch": {
"version": "2.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/multimatch/-/multimatch-2.1.0.tgz",
"integrity": "sha1-nHkGoi+0wCkZ4vX3UWG0zb1LKis=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"mute-stream": {
"version": "0.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/mute-stream/-/mute-stream-0.0.5.tgz",
"integrity": "sha1-j7+rsKmKJT0xhDMfno3rc3L6xsA=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"natural-compare": {
"version": "1.4.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/natural-compare/-/natural-compare-1.4.0.tgz",
"integrity": "sha1-Sr6/7tdUHywnrPspvbvRXI1bpPc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"nopt": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "3.0.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/nopt/-/nopt-3.0.6.tgz",
"integrity": "sha1-xkZdvwirzU2zWTF/eaxopkayj/k=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"normalize-package-data": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.3.8",
"resolved": "https://registry.npmjs.org/normalize-package-data/-/normalize-package-data-2.3.8.tgz",
"integrity": "sha1-2Bntoqne29H/pWPqQHHZNngilbs=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"normalize-range": {
"version": "0.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz",
"integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"normalize-selector": {
"version": "0.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/normalize-selector/-/normalize-selector-0.2.0.tgz",
"integrity": "sha1-0LFF62kRicY6eNIB3E/bEpPvDAM=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"num2fraction": {
"version": "1.2.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/num2fraction/-/num2fraction-1.2.2.tgz",
"integrity": "sha1-b2gragJ6Tp3fpFZM0lidHU5mnt4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"number-is-nan": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/number-is-nan/-/number-is-nan-1.0.1.tgz",
"integrity": "sha1-CXtgK1NCKlIsGvuHkDGDNpQaAR0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"oauth-sign": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "0.8.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/oauth-sign/-/oauth-sign-0.8.2.tgz",
"integrity": "sha1-Rqarfwrq2N6unsBWV4C31O/rnUM=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"object-assign": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "4.1.1",
"resolved": "https://registry.npmjs.org/object-assign/-/object-assign-4.1.1.tgz",
"integrity": "sha1-IQmtx5ZYh8/AXLvUQsrIv7s2CGM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"on-finished": {
"version": "2.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/on-finished/-/on-finished-2.3.0.tgz",
"integrity": "sha1-IPEzZIGwg811M3mSoWlxqi2QaUc=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"once": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.4.0",
"resolved": "https://registry.npmjs.org/once/-/once-1.4.0.tgz",
"integrity": "sha1-WDsap3WWHUsROsF9nFC6753Xa9E=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"onecolor": {
"version": "3.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/onecolor/-/onecolor-3.0.4.tgz",
"integrity": "sha1-daRvgNpseqpbTarhekcZi9llJJQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"onetime": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/onetime/-/onetime-1.1.0.tgz",
"integrity": "sha1-ofeDj4MUxRbwXs78vEzP4EtO14k=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"optimist": {
"version": "0.3.7",
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolved": "https://registry.npmjs.org/optimist/-/optimist-0.3.7.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-yQlBrVnkJzMokjB00s8ufLxuwNk=",
"dev": true,
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"dependencies": {
"wordwrap": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "0.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-0.0.3.tgz",
"integrity": "sha1-o9XabNXAvAAI03I0u68b7WMFkQc=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
}
}
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"optionator": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "0.8.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/optionator/-/optionator-0.8.2.tgz",
"integrity": "sha1-NkxeQJ0/TWMB1sC0wFu6UBgK62Q=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"os-homedir": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/os-homedir/-/os-homedir-1.0.2.tgz",
"integrity": "sha1-/7xJiDNuDoM94MFox+8VISGqf7M=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"pako": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.2.9",
"resolved": "https://registry.npmjs.org/pako/-/pako-0.2.9.tgz",
"integrity": "sha1-8/dSL073gjSNqBYbrZ7P1Rv4OnU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"parse-json": {
"version": "2.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/parse-json/-/parse-json-2.2.0.tgz",
"integrity": "sha1-9ID0BDTvgHQfhGkJn43qGPVaTck=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"parserlib": {
"version": "0.2.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/parserlib/-/parserlib-0.2.5.tgz",
"integrity": "sha1-hZB92GBaoGq7PdKV1QuyuPpN0Rc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"parseurl": {
"version": "1.3.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/parseurl/-/parseurl-1.3.1.tgz",
"integrity": "sha1-yKuMkiO6NIiKpkopeyiFO+wY2lY=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"path-exists": {
"version": "2.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/path-exists/-/path-exists-2.1.0.tgz",
"integrity": "sha1-D+tsZPD8UY2adU3V77YscCJ2H0s=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"path-is-absolute": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/path-is-absolute/-/path-is-absolute-1.0.1.tgz",
"integrity": "sha1-F0uSaHNVNP+8es5r9TpanhtcX18=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"path-is-inside": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/path-is-inside/-/path-is-inside-1.0.2.tgz",
"integrity": "sha1-NlQX3t5EQw0cEa9hAn+s8HS9/FM=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"path-type": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/path-type/-/path-type-1.1.0.tgz",
"integrity": "sha1-WcRPfuSR2nBNpBXaWkBwuk+P5EE=",
"dev": true
},
"performance-now": {
"version": "0.2.0",
"resolved": "https://registry.npmjs.org/performance-now/-/performance-now-0.2.0.tgz",
"integrity": "sha1-M+8wxcd9TqIcWlOGnZG1bY8lVeU=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"pify": {
"version": "2.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
"integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"pinkie": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pinkie/-/pinkie-2.0.4.tgz",
"integrity": "sha1-clVrgM+g1IqXToDnckjoDtT3+HA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"pinkie-promise": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pinkie-promise/-/pinkie-promise-2.0.1.tgz",
"integrity": "sha1-ITXW36ejWMBprJsXh3YogihFD/o=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"pipetteur": {
"version": "2.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pipetteur/-/pipetteur-2.0.3.tgz",
"integrity": "sha1-GVV2CVno0aEcsqUOyD7sRwYz5J8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"plur": {
"version": "2.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/plur/-/plur-2.1.2.tgz",
"integrity": "sha1-dIJFLBoPUI4+NE6uwxLJHCncZVo=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"pluralize": {
"version": "1.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pluralize/-/pluralize-1.2.1.tgz",
"integrity": "sha1-0aIUg/0iu0HlihL6NCGCMUCJfEU=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"postcss": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "5.2.17",
"resolved": "https://registry.npmjs.org/postcss/-/postcss-5.2.17.tgz",
"integrity": "sha1-z09Ze4ZNZcikkrLqvp1wbIecOIs=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"supports-color": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.2.3",
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-3.2.3.tgz",
"integrity": "sha1-ZawFBLOVQXHYpklGsq48u4pfVPY=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
"postcss-less": {
"version": "0.14.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/postcss-less/-/postcss-less-0.14.0.tgz",
"integrity": "sha1-xjGwicbM5CK5oQ86lY0r7dOBkyQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"postcss-media-query-parser": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.2.3",
"resolved": "https://registry.npmjs.org/postcss-media-query-parser/-/postcss-media-query-parser-0.2.3.tgz",
"integrity": "sha1-J7Ocb02U+Bsac7j3Y1HGCeXO8kQ=",
"dev": true
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"postcss-reporter": {
"version": "1.4.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/postcss-reporter/-/postcss-reporter-1.4.1.tgz",
"integrity": "sha1-wTbwpbFhkV83ndN2XGEHX357mvI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"postcss-resolve-nested-selector": {
"version": "0.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/postcss-resolve-nested-selector/-/postcss-resolve-nested-selector-0.1.1.tgz",
"integrity": "sha1-Kcy8fDfe36wwTp//C/FZaz9qDk4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"postcss-scss": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "0.3.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/postcss-scss/-/postcss-scss-0.3.1.tgz",
"integrity": "sha1-ZcYQ2OKn7g5isYNbcbiHBzSBbks=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"postcss-selector-parser": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.2.3",
"resolved": "https://registry.npmjs.org/postcss-selector-parser/-/postcss-selector-parser-2.2.3.tgz",
"integrity": "sha1-+UN3iGBsPJrO4W/+jYsWKX8nu5A=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"postcss-value-parser": {
"version": "3.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-3.3.0.tgz",
"integrity": "sha1-h/OPnxj3dKSrTIojL1xc6IcqnRU=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"prelude-ls": {
"version": "1.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/prelude-ls/-/prelude-ls-1.1.2.tgz",
"integrity": "sha1-IZMqVJ9eUv/ZqCf1cOBL5iqX2lQ=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"pretty-bytes": {
"version": "1.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/pretty-bytes/-/pretty-bytes-1.0.4.tgz",
"integrity": "sha1-CiLoIQYJrTVUL4yNXSFZr/B1HIQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"process-nextick-args": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.0.7",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/process-nextick-args/-/process-nextick-args-1.0.7.tgz",
"integrity": "sha1-FQ4gt1ZZCtP5EJPyWk8q2L/zC6M=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"progress": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.1.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/progress/-/progress-1.1.8.tgz",
"integrity": "sha1-4mDHj2Fhzdmw5WzD4Khd4Xx6V74=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"promise": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "7.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/promise/-/promise-7.1.1.tgz",
"integrity": "sha1-SJZUxpJha4qlWwck+oCbt9tJxb8=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"prr": {
"version": "0.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/prr/-/prr-0.0.0.tgz",
"integrity": "sha1-GoS4WQgyVQFBGFPQCB7j+obikmo=",
"dev": true,
"optional": true
},
"punycode": {
"version": "1.4.1",
"resolved": "https://registry.npmjs.org/punycode/-/punycode-1.4.1.tgz",
"integrity": "sha1-wNWmOycYgArY4esPpSachN1BhF4=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"qs": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "6.4.0",
"resolved": "https://registry.npmjs.org/qs/-/qs-6.4.0.tgz",
"integrity": "sha1-E+JtKK1rD/qpExLNO/cI7TUecjM=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"raw-body": {
"version": "2.1.7",
"resolved": "https://registry.npmjs.org/raw-body/-/raw-body-2.1.7.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-rf6s4uT7MJgFgBTQjActzFl1h3Q=",
"dev": true,
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"dependencies": {
"bytes": {
"version": "2.4.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/bytes/-/bytes-2.4.0.tgz",
"integrity": "sha1-fZcZb51br39pNeJZhVSe3SpsIzk=",
"dev": true
},
"iconv-lite": {
"version": "0.4.13",
"resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.4.13.tgz",
"integrity": "sha1-H4irpKsLFQjoMSrMOTRfNumS4vI=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
}
}
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"read-file-stdin": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/read-file-stdin/-/read-file-stdin-0.2.1.tgz",
"integrity": "sha1-JezP86FTtoCa+ssj7hU4fbng7mE=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"read-pkg": {
"version": "1.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/read-pkg/-/read-pkg-1.1.0.tgz",
"integrity": "sha1-9f+qXs0pyzHAR0vKfXVra7KePyg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"read-pkg-up": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/read-pkg-up/-/read-pkg-up-1.0.1.tgz",
"integrity": "sha1-nWPBMnbAZZGNV/ACpX9AobZD+wI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"readable-stream": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.2.9",
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.2.9.tgz",
"integrity": "sha1-z3jsb0ptHrQ9JkiMrJfwQudLf8g=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"readline2": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/readline2/-/readline2-1.0.1.tgz",
"integrity": "sha1-QQWWCP/BVHV7cV2ZidGZ/783LjU=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"redent": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/redent/-/redent-1.0.0.tgz",
"integrity": "sha1-z5Fqsf1fHxbfsggi3W7H9zDCr94=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"repeat-string": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.6.1",
"resolved": "https://registry.npmjs.org/repeat-string/-/repeat-string-1.6.1.tgz",
"integrity": "sha1-jcrkcOHIirwtYA//Sndihtp15jc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"repeating": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "2.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/repeating/-/repeating-2.0.1.tgz",
"integrity": "sha1-UhTFOpJtNVJwdSf7q0FdvAjQbdo=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"request": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.81.0",
"resolved": "https://registry.npmjs.org/request/-/request-2.81.0.tgz",
"integrity": "sha1-xpKJRqDgbF+Nb4qTM0af/aRimKA=",
"dev": true,
"optional": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"require-from-string": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "1.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/require-from-string/-/require-from-string-1.2.1.tgz",
"integrity": "sha1-UpyczvJzgK3+yaL5ZbZJu+5jZBg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"require-uncached": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/require-uncached/-/require-uncached-1.0.3.tgz",
"integrity": "sha1-Tg1W1slmL9MeQwEcS5WqSZVUIdM=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"resolve": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.1.7",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/resolve/-/resolve-1.1.7.tgz",
"integrity": "sha1-IDEU2CrSxe2ejgQRs5ModeiJ6Xs=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"resolve-from": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-1.0.1.tgz",
"integrity": "sha1-Jsv+k10a7uq7Kbw/5a6wHpPUQiY=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"restore-cursor": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/restore-cursor/-/restore-cursor-1.0.1.tgz",
"integrity": "sha1-NGYfRohjJ/7SmRR5FSJS35LapUE=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"right-align": {
"version": "0.1.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/right-align/-/right-align-0.1.3.tgz",
"integrity": "sha1-YTObci/mo1FWiSENJOFMlhSGE+8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"rimraf": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.6.1",
"resolved": "https://registry.npmjs.org/rimraf/-/rimraf-2.6.1.tgz",
"integrity": "sha1-wjOOxkPfeht/5cVPqG9XQopV8z0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"run-async": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/run-async/-/run-async-0.1.0.tgz",
"integrity": "sha1-yK1KXhEGYeQCp9IbUw4AnyX444k=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"rx-lite": {
"version": "3.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/rx-lite/-/rx-lite-3.1.2.tgz",
"integrity": "sha1-Gc5QLKVyZl87ZHsQk5+X/RYV8QI=",
"dev": true
},
"safe-buffer": {
"version": "5.0.1",
"resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.0.1.tgz",
"integrity": "sha1-0mPKVGls2KMGtcplUekt5XkY++c=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"sax": {
"version": "0.5.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/sax/-/sax-0.5.8.tgz",
"integrity": "sha1-1HLbIo6zMcJQaw6MFVJK25OdEsE=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"semver": {
MDL-55856 grunt: fail gracefully when node version too old 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.
2016-09-05 14:54:01 +01:00
"version": "5.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/semver/-/semver-5.3.0.tgz",
"integrity": "sha1-myzl094C0XxgEq0yaqa00M9U+U8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"shelljs": {
MDL-55835 eslint: bump to v3.7.1 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)
2016-09-01 14:27:11 +01:00
"version": "0.6.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/shelljs/-/shelljs-0.6.1.tgz",
"integrity": "sha1-7GIRvtGSBEIIj+D3Cyg3Iy7SyKg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"shifter": {
"version": "0.5.0",
"resolved": "https://registry.npmjs.org/shifter/-/shifter-0.5.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-nyS3AptrpnACdSDu+Lq4m5L/n2g=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"progress": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/progress/-/progress-0.1.0.tgz",
"integrity": "sha1-2+wMmfvC97liPhMxY75jYdXp5Ec=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"sigmund": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/sigmund/-/sigmund-1.0.1.tgz",
"integrity": "sha1-P/IfGYytIXX587eBhT/ZTQ0ZtZA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"signal-exit": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/signal-exit/-/signal-exit-3.0.2.tgz",
"integrity": "sha1-tf3AjxKH6hF4Yo5BXiUTK3NkbG0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"slice-ansi": {
"version": "0.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/slice-ansi/-/slice-ansi-0.0.4.tgz",
"integrity": "sha1-7b+JA/ZvfOL46v1s7tZeJkyDGzU=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"sntp": {
"version": "1.0.9",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/sntp/-/sntp-1.0.9.tgz",
"integrity": "sha1-ZUEYTMkK7qbG57NeJlkIJEPGYZg=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"source-map": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "0.5.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/source-map/-/source-map-0.5.6.tgz",
"integrity": "sha1-dc449SvwczxafwwRjYEzSiu19BI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"spdx-correct": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/spdx-correct/-/spdx-correct-1.0.2.tgz",
"integrity": "sha1-SzBz2TP/UfORLwOsVRlJikFQ20A=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"spdx-expression-parse": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.4",
"resolved": "https://registry.npmjs.org/spdx-expression-parse/-/spdx-expression-parse-1.0.4.tgz",
"integrity": "sha1-m98vIOH0DtRH++JzJmGR/O1RYmw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"spdx-license-ids": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.2.2",
"resolved": "https://registry.npmjs.org/spdx-license-ids/-/spdx-license-ids-1.2.2.tgz",
"integrity": "sha1-yd96NCRZSt5r0RkA1ZZpbcBrrFc=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"specificity": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "0.3.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/specificity/-/specificity-0.3.0.tgz",
"integrity": "sha1-MyRy1OXrWvIIIRcZM5mKa8Oxzm8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"split2": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/split2/-/split2-0.2.1.tgz",
"integrity": "sha1-At2smtwD7Au3jBKC7Aecpuha6QA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"sprintf-js": {
"version": "1.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz",
"integrity": "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"sshpk": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.13.0",
"resolved": "https://registry.npmjs.org/sshpk/-/sshpk-1.13.0.tgz",
"integrity": "sha1-/yo+T9BEl1Vf7Zezmg/YL6+zozw=",
"dev": true,
"optional": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"assert-plus": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/assert-plus/-/assert-plus-1.0.0.tgz",
"integrity": "sha1-8S4PPF13sLHN2RRpQuTpbB5N1SU=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"statuses": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.3.1",
"resolved": "https://registry.npmjs.org/statuses/-/statuses-1.3.1.tgz",
"integrity": "sha1-+vUbnrdKrvOzrPStX2Gr8ky3uT4=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"stream-combiner": {
"version": "0.2.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/stream-combiner/-/stream-combiner-0.2.2.tgz",
"integrity": "sha1-rsjLrBd7Vrb0+kec7YwZEs7lKFg=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"stream-counter": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/stream-counter/-/stream-counter-0.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-oDXkKTYftX82Fgbhf82Ki5Z3Mns=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"isarray": {
"version": "0.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz",
"integrity": "sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"readable-stream": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.0.34",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.0.34.tgz",
"integrity": "sha1-Elgg40vIQtLyqq+v5MKRbuMsFXw=",
"dev": true
},
"string_decoder": {
"version": "0.10.31",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz",
"integrity": "sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"string_decoder": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.1",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-1.0.1.tgz",
"integrity": "sha1-YuIA8DmVWmgQ2N8KM//A8BNmLZg=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"string-width": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-1.0.2.tgz",
"integrity": "sha1-EYvfW4zcUaKn5w0hHgfisLmxB9M=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"stringstream": {
"version": "0.0.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/stringstream/-/stringstream-0.0.5.tgz",
"integrity": "sha1-TkhM1N5aC7vuGORjB3EKioFiGHg=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"strip-ansi": {
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"version": "3.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-3.0.1.tgz",
"integrity": "sha1-ajhfuIU9lS1f8F0Oiq+UJ43GPc8=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"strip-bom": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "3.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz",
"integrity": "sha1-IzTBjpx1n3vdVv3vfprj1YjmjtM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"strip-indent": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/strip-indent/-/strip-indent-1.0.1.tgz",
"integrity": "sha1-DHlipq3vp7vUrDZkYKY4VSrhoKI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"strip-json-comments": {
"version": "1.0.4",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/strip-json-comments/-/strip-json-comments-1.0.4.tgz",
"integrity": "sha1-HhX7ysl9Pumb8tc7TGVrCCu6+5E=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"style-search": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/style-search/-/style-search-0.1.0.tgz",
"integrity": "sha1-eVjHk+R+MuB9K1yv5cC/jhLneQI=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"stylehacks": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.3.2",
"resolved": "https://registry.npmjs.org/stylehacks/-/stylehacks-2.3.2.tgz",
"integrity": "sha1-ZMg+BDimjJ7fRJ6MVSp9mrYAmws=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"minimist": {
"version": "1.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/minimist/-/minimist-1.2.0.tgz",
"integrity": "sha1-o1AIsg9BOD7sH7kU9M1d95omQoQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
"stylelint": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "7.4.1",
"resolved": "https://registry.npmjs.org/stylelint/-/stylelint-7.4.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-qqShtMBtknXmoQe9xQH5In2lXGs=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"get-stdin": {
"version": "5.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-5.0.1.tgz",
"integrity": "sha1-Ei4WFZHiH/TFJTAwVpPyDmOTo5g=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"globby": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "6.1.0",
"resolved": "https://registry.npmjs.org/globby/-/globby-6.1.0.tgz",
"integrity": "sha1-9abXDoOV4hyFj7BInWTfAkJNUGw=",
"dev": true
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
},
"is-fullwidth-code-point": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz",
"integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8=",
"dev": true
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"resolve-from": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/resolve-from/-/resolve-from-2.0.0.tgz",
"integrity": "sha1-lICrIOlP+h2egKgEx+oUdhGWa1c=",
"dev": true
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
},
"string-width": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/string-width/-/string-width-2.0.0.tgz",
"integrity": "sha1-Y1xUNsxypuDDh87KJ41OLuxSaH4=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-55167 npm: add stylelint-checkstyle-formatter Useful for automations (like the Moodle prechecker)
2016-08-02 18:52:41 +01:00
"stylelint-checkstyle-formatter": {
"version": "0.1.0",
"resolved": "https://registry.npmjs.org/stylelint-checkstyle-formatter/-/stylelint-checkstyle-formatter-0.1.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-jEAoU+kqCq6DcVZwyvY+efIRmac=",
"dev": true,
MDL-55167 npm: add stylelint-checkstyle-formatter Useful for automations (like the Moodle prechecker)
2016-08-02 18:52:41 +01:00
"dependencies": {
"lodash": {
"version": "3.10.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/lodash/-/lodash-3.10.1.tgz",
"integrity": "sha1-W/Rejkm6QYnhfUgnid/RW9FAt7Y=",
"dev": true
MDL-55167 npm: add stylelint-checkstyle-formatter Useful for automations (like the Moodle prechecker)
2016-08-02 18:52:41 +01:00
}
}
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"sugarss": {
MDL-56423 stylelint: bump to v7.4.1 Fixes a false positive with declaration-block-no-ignored-properties and display: inline.
2016-10-13 09:26:09 +01:00
"version": "0.1.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/sugarss/-/sugarss-0.1.6.tgz",
"integrity": "sha1-/jrA4eBygq7x3oSoC3I4b/Tn6jc=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"supports-color": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/supports-color/-/supports-color-2.0.0.tgz",
"integrity": "sha1-U10EXOa2Nj+kARcIRimZXp3zJMc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"svg-tags": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/svg-tags/-/svg-tags-1.0.0.tgz",
"integrity": "sha1-WPcc7jvVGbWdSyqEO2x95krAR2Q=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"synesthesia": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/synesthesia/-/synesthesia-1.0.1.tgz",
"integrity": "sha1-XvlepUjA1cbm+btLDQcx3/hkp3c=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"table": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "3.8.3",
"resolved": "https://registry.npmjs.org/table/-/table-3.8.3.tgz",
"integrity": "sha1-K7xULw/amGGnVdOUf+/Ys/UThV8=",
"dev": true,
"dependencies": {
"is-fullwidth-code-point": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-2.0.0.tgz",
"integrity": "sha1-o7MKXE8ZkYMWeqq5O+764937ZU8=",
"dev": true
},
"string-width": {
"version": "2.0.0",
"resolved": "https://registry.npmjs.org/string-width/-/string-width-2.0.0.tgz",
"integrity": "sha1-Y1xUNsxypuDDh87KJ41OLuxSaH4=",
"dev": true
}
}
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"text-table": {
"version": "0.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/text-table/-/text-table-0.2.0.tgz",
"integrity": "sha1-f17oI66AUgfACvLfSoTsP8+lcLQ=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"through": {
"version": "2.3.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/through/-/through-2.3.8.tgz",
"integrity": "sha1-DdTJ/6q8NXlgsbckEV1+Doai4fU=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"through2": {
"version": "0.6.5",
"resolved": "https://registry.npmjs.org/through2/-/through2-0.6.5.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-QaucZ7KdVyCQcUEOHXp6lozTrUg=",
"dev": true,
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"dependencies": {
"isarray": {
"version": "0.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz",
"integrity": "sha1-ihis/Kmo9Bd+Cav8YDiTmwXR7t8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
"readable-stream": {
"version": "1.0.34",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.0.34.tgz",
"integrity": "sha1-Elgg40vIQtLyqq+v5MKRbuMsFXw=",
"dev": true
},
"string_decoder": {
"version": "0.10.31",
"resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz",
"integrity": "sha1-YuIDvEF2bGwoyfyEMB2rHFMQ+pQ=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
}
}
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"timethat": {
"version": "0.0.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/timethat/-/timethat-0.0.3.tgz",
"integrity": "sha1-OoRUYguF5vnLS2f43TTciA1JrtA=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"tiny-lr": {
"version": "0.2.1",
"resolved": "https://registry.npmjs.org/tiny-lr/-/tiny-lr-0.2.1.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-s/26gC5dVqM8L28QeUsy5Hescp0=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"debug": {
"version": "2.2.0",
"resolved": "https://registry.npmjs.org/debug/-/debug-2.2.0.tgz",
"integrity": "sha1-+HBX6ZWxofauaklgZkE3vFbwOdo=",
"dev": true
},
"ms": {
"version": "0.7.1",
"resolved": "https://registry.npmjs.org/ms/-/ms-0.7.1.tgz",
"integrity": "sha1-nNE8A62/8ltl7/3nzoZO6VIBcJg=",
"dev": true
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"qs": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "5.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/qs/-/qs-5.1.0.tgz",
"integrity": "sha1-TZMuXH6kEcynajEtOaYGIA/VDNk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"tough-cookie": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "2.3.2",
"resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-2.3.2.tgz",
"integrity": "sha1-8IH3bkyFcg5sN6X6ztc3FQ2EByo=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"trim-newlines": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/trim-newlines/-/trim-newlines-1.0.0.tgz",
"integrity": "sha1-WIeWa7WCpFA6QetST301ARgVphM=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"tryit": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.0.3",
"resolved": "https://registry.npmjs.org/tryit/-/tryit-1.0.3.tgz",
"integrity": "sha1-OTvnMKlEb9Hq1tpZoBQwjzbCics=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"tunnel-agent": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.6.0",
"resolved": "https://registry.npmjs.org/tunnel-agent/-/tunnel-agent-0.6.0.tgz",
"integrity": "sha1-J6XeoGs2sEoKmWZ3SykIaPD8QP0=",
"dev": true,
"optional": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"tweetnacl": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "0.14.5",
"resolved": "https://registry.npmjs.org/tweetnacl/-/tweetnacl-0.14.5.tgz",
"integrity": "sha1-WuaBd/GS1EViadEIr6k/+HQ/T2Q=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"type-check": {
"version": "0.3.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/type-check/-/type-check-0.3.2.tgz",
"integrity": "sha1-WITKtRLPHTVeP7eE8wgEsrUg23I=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"type-is": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.6.15",
"resolved": "https://registry.npmjs.org/type-is/-/type-is-1.6.15.tgz",
"integrity": "sha1-yrEPtJCeRByChC6v4a1kbIGARBA=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"typedarray": {
"version": "0.0.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/typedarray/-/typedarray-0.0.6.tgz",
"integrity": "sha1-hnrHTjhkGHsdPUfZlqeOxciDB3c=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"uglify-js": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "2.6.4",
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-2.6.4.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-ZeovswWck5RpLxX+2HwrNsFrmt8=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"async": {
"version": "0.2.10",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/async/-/async-0.2.10.tgz",
"integrity": "sha1-trvgsGdLnXGXCMo43owjfLUmw9E=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"uglify-to-browserify": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uglify-to-browserify/-/uglify-to-browserify-1.0.2.tgz",
"integrity": "sha1-bgkk1r2mta/jSeOabWMoUKD4grc=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"underscore": {
"version": "1.6.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/underscore/-/underscore-1.6.0.tgz",
"integrity": "sha1-izixDKze9jM3uLJOT/htRa6lKag=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"underscore.string": {
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"version": "3.2.3",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/underscore.string/-/underscore.string-3.2.3.tgz",
"integrity": "sha1-gGmSYzZl1eX8tNsfs6hi62jp5to=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"uniq": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uniq/-/uniq-1.0.1.tgz",
"integrity": "sha1-sxxa6CVIRKOoKBVBzisEuGWnNP8=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"unpipe": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/unpipe/-/unpipe-1.0.0.tgz",
"integrity": "sha1-sr9O6FFKrmFltIF4KdIbLvSZBOw=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"uri-path": {
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uri-path/-/uri-path-1.0.0.tgz",
"integrity": "sha1-l0fwGDWJM8Md4PzP2C0TjmcmLjI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"user-home": {
"version": "2.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/user-home/-/user-home-2.0.0.tgz",
"integrity": "sha1-nHC/2Babwdy/SGBODwS4tJzenp8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"util-deprecate": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz",
"integrity": "sha1-RQ1Nyfpw3nMnYvvS1KKJgUGaDM8=",
"dev": true
},
"uuid": {
"version": "3.0.1",
"resolved": "https://registry.npmjs.org/uuid/-/uuid-3.0.1.tgz",
"integrity": "sha1-ZUS7ot/ajBzxfmKaOjBeK7H+5sE=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"validate-npm-package-license": {
"version": "3.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/validate-npm-package-license/-/validate-npm-package-license-3.0.1.tgz",
"integrity": "sha1-KAS6vnEq0zeUWaz74kdGqywwP7w=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"verror": {
"version": "1.3.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/verror/-/verror-1.3.6.tgz",
"integrity": "sha1-z/XfEpRtKX0rqu+qJoniW+AcAFw=",
"dev": true,
"optional": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"walkdir": {
"version": "0.0.11",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/walkdir/-/walkdir-0.0.11.tgz",
"integrity": "sha1-oW0CXrkxvQO1LzCMrtD0D86+lTI=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"watch": {
"version": "0.8.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/watch/-/watch-0.8.0.tgz",
"integrity": "sha1-G7DupT3v5uYh6cjGPANYAH7L28w=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
"websocket-driver": {
"version": "0.6.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/websocket-driver/-/websocket-driver-0.6.5.tgz",
"integrity": "sha1-XLJVbOuF9Dc8bYI4qmkchFThOjY=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
"websocket-extensions": {
"version": "0.1.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/websocket-extensions/-/websocket-extensions-0.1.1.tgz",
"integrity": "sha1-domUmcGEtu91Q3fC27DNbLVdKec=",
"dev": true
MDL-55048 grunt/npm: Update dependencies * 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
2016-06-28 17:45:11 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"which": {
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"version": "1.2.14",
"resolved": "https://registry.npmjs.org/which/-/which-1.2.14.tgz",
"integrity": "sha1-mofEN48D6CfOyvGs31bHNsAcFOU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"window-size": {
"version": "0.1.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/window-size/-/window-size-0.1.0.tgz",
"integrity": "sha1-VDjNLqk7IC76Ohn+iIeu58lPnJ0=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"wordwrap": {
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"version": "1.0.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/wordwrap/-/wordwrap-1.0.0.tgz",
"integrity": "sha1-J1hIEIkUVqQXHI0CJkQa3pDLyus=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
"wrappy": {
"version": "1.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
"integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
"write": {
"version": "0.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/write/-/write-0.2.1.tgz",
"integrity": "sha1-X8A4KOJkzqP+kUVUdvejxWbLB1c=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
"write-file-stdout": {
"version": "0.0.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/write-file-stdout/-/write-file-stdout-0.0.2.tgz",
"integrity": "sha1-wlLXx8WxtAKJdjDjRTx7/mkNnKE=",
"dev": true
MDL-55167 grunt: add stylelint css linting
2016-07-05 15:56:53 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"xml2js": {
"version": "0.2.8",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/xml2js/-/xml2js-0.2.8.tgz",
"integrity": "sha1-m4FpCTFjH/CdGVdUn69U9PmAs8I=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
MDL-52127 grunt: be aware of third party paths 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).
2016-05-13 21:20:21 +01:00
"xmldom": {
"version": "0.1.22",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/xmldom/-/xmldom-0.1.22.tgz",
"integrity": "sha1-EN5OXpZJgfA8jMcvrcCNFLbDqiY=",
"dev": true
MDL-52127 grunt: be aware of third party paths 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).
2016-05-13 21:20:21 +01:00
},
"xpath": {
"version": "0.0.23",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/xpath/-/xpath-0.0.23.tgz",
"integrity": "sha1-9ej9xr3H5yiFsyNPQMuiZpWAqvo=",
"dev": true
MDL-52127 js: check amd files with eslint grunt task 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.
2016-05-11 10:19:30 +01:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"xtend": {
"version": "4.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/xtend/-/xtend-4.0.1.tgz",
"integrity": "sha1-pcbVMr5lbiPbgg77lDofBJmNY68=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"yargs": {
"version": "3.10.0",
"resolved": "https://registry.npmjs.org/yargs/-/yargs-3.10.0.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-9+572FfdfB0tOMDnTvvWgdFDH9E=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"camelcase": {
"version": "1.2.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/camelcase/-/camelcase-1.2.1.tgz",
"integrity": "sha1-m7UwTS4LVmmLLHWLCKPqqdqlijk=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
}
}
},
"ycssmin": {
"version": "1.0.1",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/ycssmin/-/ycssmin-1.0.1.tgz",
"integrity": "sha1-fN3o23jPqwDSkBw7IwHjBPr03xY=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"yuglify": {
"version": "0.1.4",
"resolved": "https://registry.npmjs.org/yuglify/-/yuglify-0.1.4.tgz",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"integrity": "sha1-cm1eSvgQ90HvIYZfb5VMQHijpF8=",
"dev": true,
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"dependencies": {
"nopt": {
"version": "2.1.2",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/nopt/-/nopt-2.1.2.tgz",
"integrity": "sha1-bMzZd7gBMqB3MdbozljCyDA8+a8=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
},
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
"uglify-js": {
"version": "1.3.5",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/uglify-js/-/uglify-js-1.3.5.tgz",
"integrity": "sha1-S1v/+Rhu/7qoiOTJ6UvZ/EyUkp0=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"yui-lint": {
"version": "0.2.0",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/yui-lint/-/yui-lint-0.2.0.tgz",
"integrity": "sha1-6RPadPqgZPtTwDdxstMSk4ZfAYU=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"yuicompressor": {
"version": "2.4.7",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/yuicompressor/-/yuicompressor-2.4.7.tgz",
"integrity": "sha1-GAyheDRsb+MrbuilCyrrV+TUWEQ=",
"dev": true
MDL-49817 grunt: add watch task This allows files to be watched and automatically build when changed. Thanks to David Monllaó for the initial basis for this patch.
2016-01-14 13:22:28 +00:00
},
"yuitest-coverage": {
"version": "0.0.6",
MDL-59094 npm: Update shrinkwrap file to npm 5 generated 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
2017-05-31 09:48:37 +01:00
"resolved": "https://registry.npmjs.org/yuitest-coverage/-/yuitest-coverage-0.0.6.tgz",
"integrity": "sha1-+DnXLTStIzZxlDfKvK5ahcO/XKg=",
"dev": true
MDL-52250 npm: shrinkwrap to lock down dependencies 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)
2015-12-03 17:00:50 +00:00
}
}
}
Reference in New Issue Copy Permalink