ylqjgm
/
canvas-lms
mirror of https://github.com/instructure/canvas-lms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
canvas-lms/package.json

199 lines
7.5 KiB
JSON
Raw Normal View History

AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
{
"name": "canvas-lms",
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"license": "AGPL-3.0",
AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
"version": "0.0.0",
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"engines": {
Use node 8.10.0 instead of 8.9.4 Test plan: * automated builds should pass * docker stuff should work Change-Id: I120e5689b6b219dc295517e92047cdf3f8b5d61e Reviewed-on: https://gerrit.instructure.com/143022 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-09 04:33:46 +08:00
"node": ">=8.10.0",
upgrade yarn to 1.6.0 Change-Id: Icc59c9c43fea079196d9a0dc29b23ac0f1da74c7 Reviewed-on: https://gerrit.instructure.com/147047 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Derek Bender <djbender@instructure.com> QA-Review: Derek Bender <djbender@instructure.com>
2018-04-17 00:03:30 +08:00
"yarn": "1.6.0"
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
},
move napa from "devDependencies" to "dependencies" Change-Id: I4dde9458868cd5c1c41b921414dff4b3dc9371de Reviewed-on: https://gerrit.instructure.com/29878 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Jason Madsen <jmadsen@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-02-11 02:29:11 +08:00
"dependencies": {
Fix so we don’t include 2 copies of all InstUI stuff If we are going to use a dev build of instUI we have to do this To make sure everything still shares the same version. We need to be very careful with our updates to yarn.lock that there is only ever 1 entry per inst-ui package in the same major version range. Otherwise our client code will get super bloated and things will start breaking in subtle unexpected ways (from having 2 copies of same lib on the page) Change-Id: Iab90131bae9e10a954ca2d5aef049a90eefb9a39 Reviewed-on: https://gerrit.instructure.com/148809 Reviewed-by: Ed Schiebel <eschiebel@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-05-02 01:28:45 +08:00
"@instructure/ui-alerts": "5.4.1-dev.1",
"@instructure/ui-buttons": "5.4.1-dev.1",
Upgrade instUI from 4.7.3 to 4.8.0 Fixes: CORE-1105 CORE-1106 CORE-1174 Test plan (for CORE-1105 CORE-1106): * using the keyboard, go to /accounts/x/users * you should be able to hit “enter” to click on the “Act As” or “Send Message” icon links Test plan (for CORE-1174): * set your feature flags so you use the RTL layout * the navigation tray, RCE a11y checker, etc should pop in from the opposite side of the page than the did in normal LTR layout Change-Id: I25d664bfd94970f4bbb37ba8ebe5c72cc9e5b3ff Reviewed-on: https://gerrit.instructure.com/144969 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-28 01:19:12 +08:00
"@instructure/ui-core": "^4.8.0",
Fix so we don’t include 2 copies of all InstUI stuff If we are going to use a dev build of instUI we have to do this To make sure everything still shares the same version. We need to be very careful with our updates to yarn.lock that there is only ever 1 entry per inst-ui package in the same major version range. Otherwise our client code will get super bloated and things will start breaking in subtle unexpected ways (from having 2 copies of same lib on the page) Change-Id: Iab90131bae9e10a954ca2d5aef049a90eefb9a39 Reviewed-on: https://gerrit.instructure.com/148809 Reviewed-by: Ed Schiebel <eschiebel@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-05-02 01:28:45 +08:00
"@instructure/ui-menu": "5.4.1-dev.1",
"@instructure/ui-overlays": "5.4.1-dev.1",
"@instructure/ui-themeable": "5.4.1-dev.1",
"@instructure/ui-themes": "5.4.1-dev.1",
upgrade to apollo 2.1 closes RECNVS-377 Test plan: make sure student context cards work Change-Id: Ib306e0be5d51f68afad0ff112bf745d9e0ad1d5b Reviewed-on: https://gerrit.instructure.com/145501 Tested-by: Jenkins Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> QA-Review: Collin Parrish <cparrish@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com>
2018-03-27 01:32:21 +08:00
"apollo-boost": "^0.1.4",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"axios": "^0.16.0",
"backbone": "1.1.1",
Remove remaining dynamic brand css code closes: CNVS-39103 CNVS-39104 CNVS-38650 test plan: * do a general css styling regression pass * make sure that the urls to css files look like /dist/brandable_css/new_styles_normal_contrast/<bundle>-<fingerprint>.css and not: /dist/brandable_css/<big long md5>/new_styles_normal_contrast/<bundle>-<fingerprint>.css * make sure that stylesheets loaded by handlebars templates work eg: go to the calendar page and make sure it is styled correctly * verify that the theme editor works. especially the process when you hit "preivew" and "apply" * set up config/canvas_cdn.yml to use the dev cdn * run `bundle exec canvas:compile_assets && bundle exec rake canvas:cdn:upload_to_s3` * load a page, all the css should load from the cdn * verify the theme editor works when using the cdn too. * also review the changes in the brandable_css npm package: https://github.com/ryankshaw/brandable_css/compare/c6bef...b159d5 Change-Id: I55db41e90f6bc54183a661128f1050445a086d6b Reviewed-on: https://gerrit.instructure.com/120912 Tested-by: Jenkins Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-26 07:19:15 +08:00
"brandable_css": "0.1.0",
don’t cp all of canvas-planner’s node_modules dir this is to prevent canvas from copying everything in canvas-planner’s node_modules dir into /node_modules/canvas-planner/node_modules this will mimic the exact same behavior that pushing it to the npm repository and pulling it from there in canvas’s package.json test plan: * do `ls node_modules/canvas-planner/node_modules/jest*` * you should get: ls: node_modules/canvas-planner/\ node_modules/jest*: No such file or directory Change-Id: Ie428b3d0a5d6cc1d9bec89ae00adb3d451dfc916 Reviewed-on: https://gerrit.instructure.com/139907 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-02-06 04:41:27 +08:00
"canvas-planner": "file:./packages/canvas-planner/copy-of-what-gets-published-to-npm-registry",
move canvas-rce to canvas-lms/packages/canvas-rce closes CORE-994 refs RECNVS-398 refs CORE-1224 closes CORE-1237 test plan: - yarn install - smoke test rce - tests pass Change-Id: Ieaff024fa89879fac3e7edf99381f46de921cce2 Reviewed-on: https://gerrit.instructure.com/145671 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-04-03 05:52:07 +08:00
"canvas-rce": "file:./packages/canvas-rce/canvas",
Update canvas_offline_course_viewer for new translations Test plan - Smoke test to ensure dependency pinning hasn't caused any issues Change-Id: I98f2feec9c56f98f530685fa9c94c106d9881c4c Reviewed-on: https://gerrit.instructure.com/122023 Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Product-Review: Jon Willesen <jonw+gerrit@instructure.com> Tested-by: Jenkins QA-Review: Nathan Rogowski <nathan@instructure.com>
2017-08-09 03:40:06 +08:00
"canvas_offline_course_viewer": "https://github.com/instructure/canvas_offline_course_viewer.git#1.2.0",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"classnames": "^2.2.5",
"color-slicer": "0.8.0",
upgrade d3 to latest 3.x version the previous version caused an error when building native dependencies during the yarn install when using node 8. refs CORE-704 test plan: - ensure d3 charts in gradezilla/OutcomeColumnView render correctly - ensure d3 charts in gradebook/OutcomeColumnView render correctly - ensure d3 charts in grade_summary/OutcomeLineGraphView render correctly - ensure d3 charts in client_apps/canvas_quizzes render correctly - yarn install runs without errors using latest node 8 lts Change-Id: Ib2f8d4acab6060795b50e545eb64f324587b6300 Reviewed-on: https://gerrit.instructure.com/134476 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Leo Abner <rabner@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2017-12-04 23:24:41 +08:00
"d3": "3.5.17",
Handle dependent variables in the theme editor After the theme editor refactor dependant variables were not working. This fixes it. This also makes it so that override files are handled properly. closes CORE-1085 Test Plan: - Go to the theme editor with a new theme - Change the "Primary Brand Color" - "Primary Button" should change as well - Preview the changes - Change should be reflected after the preview loads - Repeat that again, the same behavior should occur. - Change the "Primary Button" color and preview - The two items should now be "unlinked" and they change independent of one another - Upload a js override - Preview changes - Upload a css override - Preview changes - Both the js and the css fields should be populated Change-Id: I61572a3c5bdf4f63c82078dff492dc504d0af7bf Reviewed-on: https://gerrit.instructure.com/142395 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-03-02 07:12:40 +08:00
"formdata-polyfill": "^3.0.9",
Fix calendar event cutoff for specific time ranges The actual fix was applied to the fullcalendar package we are using. This just bumps our local version to apply the fix in canvas-lms. The fix in fullcalendar can be seen here: https://github.com/instructure/fullcalendar/pull/1/files fixes COMMS-268 Test Plan: - Navigate to the calendar - Create a new 50 minute even (ie, from 8:00 to 8:50) with a title - Switch the calendar to week view - Notice that the bottom half of the title is not cut off Change-Id: I084e085d7a97039df7729870271a8691e010e4ba Reviewed-on: https://gerrit.instructure.com/137608 Reviewed-by: Ryan Shaw <ryan@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Venk Natarajan <vnatarajan@instructure.com> Product-Review: Landon Gilbert-Bland <lbland@instructure.com>
2018-01-12 00:59:21 +08:00
"fullcalendar": "https://github.com/instructure/fullcalendar.git#1108dd1c991a029ec6fd7de3337737ec5295ba97",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"graphiql": "^0.11.2",
upgrade to apollo 2.1 closes RECNVS-377 Test plan: make sure student context cards work Change-Id: Ib306e0be5d51f68afad0ff112bf745d9e0ad1d5b Reviewed-on: https://gerrit.instructure.com/145501 Tested-by: Jenkins Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> QA-Review: Collin Parrish <cparrish@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com>
2018-03-27 01:32:21 +08:00
"graphql": "^0.13.2",
"graphql-tag": "^2.8.0",
Get i18n-js and i18nliner from npm, not vendor closes: CORE-1201 test plan: * the qunit & selenium tests that we have around this should still pass (except for that one that had to be changed because the spec was actually expecting the wrong thing and the old code was erroneous) * load the app in fully production build and make sure translations still work Change-Id: Id06c38f60c1670fb93e85d5479ec747035c1158b Reviewed-on: https://gerrit.instructure.com/143456 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-03-14 04:10:14 +08:00
"i18n-js": "^3",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"ic-ajax": "~2.0.1",
"ic-tabs": "0.1.3",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"immutability-helper": "^2",
"instructure-icons": "^4",
Make it so it works with newest yarn (1.3.2) test plan: * while running yarn 0.27, * run `yarn` * it should work and there should only be one jquery in node_modules * brew upgrade yarn (or whatever else you do to upgrade yarn to 1.3.2) * run `yarn` * it should work and not make any changes to yarn.lock or node_modules Change-Id: Idf2eefbc1707d4c77ec8d1d6a78909240fd9b9f9 Reviewed-on: https://gerrit.instructure.com/133500 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-22 04:03:43 +08:00
"jquery": "https://github.com/ryankshaw/jquery.git#a755a3e9c99d5a70d8ea570836f94ae1ba56046d",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"jquery-getscrollbarwidth": "^1.0.0",
"jquery-ui-touch-punch": "^0.2.3",
"jquery.cookie": "^1.4.1",
Update yarn/npm dependencies this will make it so we can use karma with the latest node. once the commit to upgrade d3 is merged, that was the only other thing we needed to do to have everything working on node 8. Change-Id: I820b27ee3da38818b69554c6e409a2177370ca34 Reviewed-on: https://gerrit.instructure.com/136752 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-01-03 06:24:44 +08:00
"jquery.elastic": "1.0.0",
get window.location.orgin polyfill from npm …instead of the copy-pasta’ed one in our repo Test plan: Make sure the files search results page works in ie11 Change-Id: I61433363eda53d44b897bf1f88837cef7c239f87 Reviewed-on: https://gerrit.instructure.com/135141 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-09 08:32:58 +08:00
"location-origin": "^1.1.4",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"lodash": "^4.16.4",
"md5": "^2.2.1",
Upgrade mediaelement to latest master of our fork Fixes: CORE-1091 show controls when they receive focus (#39) if controls are visibly hidden, they should still be tabbable for accessibility, and when they get keyboard-focused, they should become visible again. See: https://github.com/instructure/mediaelement/commit/0402b2b76 Change-Id: Ic655d43a64d111662f8d7368f21032664a8aee74 Reviewed-on: https://gerrit.instructure.com/142693 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-07 00:03:37 +08:00
"mediaelement": "https://github.com/instructure/mediaelement.git#master",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"moment": "~2.10.6",
Get slickGrid to work in RTL Closes: CORE-1226 This gets both the old gradebook and the new gradezilla gradebook to work in RTL. Test plan: * in both old gradebook and new gradezilla gradebook: * go to the gradebook in normal LTR interface * everything should work exactly as before * turn on the RTL feature flag either in your user settings or by turning int on in accounts/x/settings and then setting your lang to arabic Specific things to test: * try it on both the old gradebook and the new gradezilla gradebook * try it on a really large gradebook with tons of rows and columns * try a really small gradebook with less columns than there is screen width * try it in different browsers. Since each browser has different scrollLeft handling in RTL, I normalized it. but verify that it works in each * try resizing and reordering columns * borders and other styles should be flipped to the opposite side in RTL * make sure keyboard shortcuts (like the left, right, top, down arrow keys) work and move you in the right direction in both LTR and RTL (Eg: if you are on “assignment 2”, right arrow goes to “assignment 3” In LTR but in RTL it goes back to “assignment 1”) * try to think of other places that might have used the .r<column index> or .l<column index> classnames to make sure the use the new, RTL-aware ‘.b’ and ‘.f’ (those stand for “back” and “front”) classnames This change started from this pull request: https://github.com/mleibman/SlickGrid/pull/666 but there was a lot that still needed to be done there and we needed change things to handle our frozen columns. Some interesting trivia: * in RTL, different browsers have different ways of handling scrollLeft. they all show the element scrolled all the way to the right by default (So you see the first columns) but chrome tells you scrollLeft is some large number to reflect how far from the left you’d have to scroll to get there if you scrolled all the way to the right like it should. Safari says scrollLeft is 0 by default and then as you scroll left to to see the rest of the columns, it counts down and shows a negative number. And IE does something else. So you have to do some trickery to normalize them all to be a consistent value, and that is why this pulled in that NPM module Change-Id: Id00025db0918cbc2d354e96af88023e70e041e58 Reviewed-on: https://gerrit.instructure.com/144672 Tested-by: Jenkins Reviewed-by: Jeremy Neander <jneander@instructure.com> Reviewed-by: Spencer Olson <solson@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-03-31 03:07:41 +08:00
"normalize-scroll-left": "^0.1.2",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"page": "visionmedia/page.js#1.6.4",
update parse-decimal-number to 1.0.0 A hack can be removed for parsing numbers now that 1.0.0 incorporates the needed behavior. test plan: * verify Jenkins passes Change-Id: Ifaea8fd348f4f804e9a6042fb392c699badeea6e Reviewed-on: https://gerrit.instructure.com/138046 Tested-by: Jenkins Reviewed-by: Derek Bender <djbender@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Jeremy Neander <jneander@instructure.com> QA-Review: Jeremy Neander <jneander@instructure.com>
2018-01-17 00:52:42 +08:00
"parse-decimal-number": "1.0.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"prop-types": "^15",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"qs": "https://github.com/hapijs/qs.git#a341cdf2fadba5ede1ce6c95c7051f6f31f37b81",
"react": "0.14.9",
"react-addons-css-transition-group": "0.14.8",
"react-addons-pure-render-mixin": "0.14.8",
upgrade to apollo 2.1 closes RECNVS-377 Test plan: make sure student context cards work Change-Id: Ib306e0be5d51f68afad0ff112bf745d9e0ad1d5b Reviewed-on: https://gerrit.instructure.com/145501 Tested-by: Jenkins Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> QA-Review: Collin Parrish <cparrish@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com>
2018-03-27 01:32:21 +08:00
"react-apollo": "^2.1.1",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"react-crop": "^4.0.2",
"react-dnd": "2.1.4",
"react-dnd-html5-backend": "2.1.2",
"react-dom": "0.14.9",
"react-modal": "1.6.5",
"react-redux": "4.4.5",
"react-select-box": "https://github.com/instructure-react/react-select-box.git#b1ddd39223d48793fbe3dc4e87aca00d57197b5f",
"react-tokeninput": "2.4.0",
"redux": "^3.5.2",
"redux-actions": "0.11.0",
"redux-thunk": "2.1.0",
"spin.js": "2.3.2",
"swfobject": "^2.2.1",
"tablesorter": "^2.28.5",
bump timezone.js closes CORE-577 test plan: * smoke test some datetime pickers, and maybe try a language or two Change-Id: I808d64c20e89ed287a38fda5f00d61a8f422bae7 Reviewed-on: https://gerrit.instructure.com/139326 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Cody Cutrer <cody@instructure.com>
2018-01-27 05:55:38 +08:00
"timezone": "1.0.13",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"tinycolor2": "1.4.1",
Bump canvas-rce to 3.1.0 closes CORE-1012 closes CORE-1074 closes CORE-722 Test Plan: * Changes from 3.0.3 - Smoke test of RCE, potential UI issues (This was adding support for tinymce@4.7.x) * Changes from 3.1.0 - Upload an image - Notice that the image thumbnail loads without needing a page refresh Change-Id: I0a0320b487c93b49346c1d2d730c375738b1fa2b Reviewed-on: https://gerrit.instructure.com/143497 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-03-14 05:52:57 +08:00
"tinymce": "4.7.9",
Upgrade tinymce-a11y-checker to 1.4.0 test plan: * in canvas, go to a page with a text editor (like a wiki page) and click the "a11y checker" button in the editor toolbar * the widgets that appear in the trays on the right of the page should work. look at the trays, the buttons, the text inputs, etc. Change-Id: I43476620c5a1d8cf666e20b9495dd499791a4ee4 Reviewed-on: https://gerrit.instructure.com/143347 Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-13 05:58:48 +08:00
"tinymce-a11y-checker": "~1.4.0",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"tinymce-light-skin": "1.3.1"
move napa from "devDependencies" to "dependencies" Change-Id: I4dde9458868cd5c1c41b921414dff4b3dc9371de Reviewed-on: https://gerrit.instructure.com/29878 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Jason Madsen <jmadsen@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-02-11 02:29:11 +08:00
},
AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
"devDependencies": {
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"axe-core": "~2.1.7",
"babel-cli": "^6",
"babel-core": "^6",
"babel-eslint": "^8",
"babel-jest": "^22",
"babel-loader": "^7",
Bump Babel to version 6 closes CNVS-29019 closes gh-817 Test Plan: - bundle exec rake canvas:compile_assets should compile /app/jsx and /specs/javascripts/jsx properly - Automated tests should pass - Areas of Canvas that use JSX/ES6 should work properly such as Moderated Grading, Files, and the new Admin search page Change-Id: Ic2aefbe98dd65a9b38407a68dc569e19a9e300e2 Reviewed-on: https://gerrit.instructure.com/78232 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Heath Hales <hhales@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2016-07-09 00:16:46 +08:00
"babel-plugin-add-module-exports": "0.2.1",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"babel-plugin-transform-react-remove-prop-types": "^0.4",
"babel-plugin-transform-runtime": "^6",
"babel-polyfill": "^6",
"babel-preset-env": "^1",
"babel-preset-react": "^6",
"babel-preset-stage-1": "^6",
"babel-register": "^6",
"coffee-loader": "~0.7.2",
"coffee-script": "^1",
"concurrently": "^3",
"core-js-builder": "^2",
"css-loader": "^0.28",
use web pack closes CNVS-24124 makes working with web pack possible in canvas instead of require-js. See doc/working_with_webpack.md for instructions. TEST PLAN: Nothing should change in non-webpack'd behavior Things should mostly work when you use the USE_WEBPACK environment variable, but make sure to document and ticket things that don't Change-Id: I493a259a609e9e183950bc57aa5876df70108547 Reviewed-on: https://gerrit.instructure.com/64386 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ethan Vizitei <evizitei@instructure.com> QA-Review: Ethan Vizitei <evizitei@instructure.com>
2015-10-01 11:16:11 +08:00
"ember-template-compiler": "^1.8.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"enzyme": "^2",
Ensure code sent to browsers is es5 …so it works in safari10 & IE11 Closes: CORE-1280 test plan: * run yarn * go into a file in node_modules that is used in a webpack bundle (Eg: node_modules/react-dom/index.js) and change a `var` to a `const` or a `let` and a `function` to an arrow () => function. * run `yarn webpack-production` * it should fail with errors Change-Id: Ic1589d3c1cc266eb5be22cb4716465818d0e98b6 Reviewed-on: https://gerrit.instructure.com/146496 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-04-11 00:36:43 +08:00
"es-check": "^2",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"eslint": "^4",
Update a bunch of npm dependencies Change-Id: I089fa97c1e18417f52e7b3baa9ba618129820755 Reviewed-on: https://gerrit.instructure.com/133722 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-23 03:07:54 +08:00
"eslint-config-airbnb": "^16.1.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"eslint-config-prettier": "^2",
"eslint-plugin-import": "^2",
"eslint-plugin-jest": "^21",
"eslint-plugin-jsx-a11y": "^6",
"eslint-plugin-notice": "^0.6",
"eslint-plugin-promise": "^3",
"eslint-plugin-qunit": "^3",
"eslint-plugin-react": "^7",
"exports-loader": "^0.7",
"expose-loader": "^0.7",
git rid of our vendor’ed fork of mediaelement refs: CORE-24 test plan: * this net result of this change should mean that we are using the exact same code as we were using before, just pulled from github directly in our package.json instead of vendored into our repo. * testing the follow-on commits should show this worked correctly Change-Id: Ie6d022d5fe8ed1a607f66f9d426c47ec7e8f5b14 Reviewed-on: https://gerrit.instructure.com/142381 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-02 06:35:05 +08:00
"file-loader": "^1.1.10",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"fontfaceobserver": "^2",
update gglobby npm dep refs: CNVS-29725 test plan: * run `node script/xsslint.js` * it should work (this is ran by jenkins so reall if it passes, it is good) Change-Id: Ib9b68e486c32c91e3c430cea095a628daf51db2b Reviewed-on: https://gerrit.instructure.com/87181 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-08-09 07:39:19 +08:00
"gglobby": "0.0.3",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"glob": "^7",
"gulp": "^3",
"gulp-file": "^0.4",
"gulp-filter": "^5",
"gulp-insert": "^0.5",
"gulp-load-plugins": "^1",
"gulp-rename": "^1",
"gulp-rev": "^8",
"gulp-sourcemaps": "^2",
"gulp-uglify": "^3",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"handlebars": "1.3.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"handlebars-loader": "^1",
upgrade webpack related npm modules Refs: CNVS-38653 This upgrades us to webpack 3.5.4 and upgrades uglify and Istanbul related stuff too: Test plan: * automated build should pass * run yarn && COVERAGE=1 yarn test && open coverage-js/index.html * it should run karma & open your browser to a bunch of istambul reports * run `yarn run webpack-production` * it should generate minified code that works in your browser when you open canvas in prod mode Change-Id: Id8b3c2457f47a30f299eafc6a8206102cfe98dc5 Reviewed-on: https://gerrit.instructure.com/122993 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-08-15 07:07:13 +08:00
"happypack": "^3.1.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"imports-loader": "^0.8",
"istanbul-instrumenter-loader": "^3",
"jest": "^22",
"jest-junit": "^3",
"jest-localstorage-mock": "^2",
"json-loader": "^0.5.7",
web pack port of quiz statistics refs CNVS-25916 remove dynamic requirements for env configs, use separate jsx loader for client apps, update client app plugin to use old react version, rewrite selenium spec to be an integration test rather than executing arbitrary javascript, and MAJORLY refactor loading patterns of client apps to avoid sharing code with differences delineated by opaque require re-writes. Also moved some code that was in "common" client app but only used by one actual client app down into the app that uses it (simplifies dependency tracing). TEST PLAN: 1) make sure quiz statistics still works ok under require js build, no behavior should have changed 2) also make sure quiz log auding works under require-js Change-Id: I0e5ee3eda9da16e0ad48cf858761735c71df801c Reviewed-on: https://gerrit.instructure.com/69804 Tested-by: Jenkins Reviewed-by: Ryan Taylor <rtaylor@instructure.com> QA-Review: Michael Hargiss <mhargiss@instructure.com> Product-Review: Ethan Vizitei <evizitei@instructure.com>
2016-01-07 06:31:33 +08:00
"jsx-loader": "0.11.2",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma": "^2",
"karma-chrome-launcher": "^2",
"karma-coverage-istanbul-reporter": "^1",
Make changes for node 12/iojs. This makes a number of changes to get the compilation compatible with node 12 and iojs. - removes loom (no longer used) - updates karma dependencies to more recent versions - minor css change to make sass compilation work with node-sass (lib-sass) test plan: - should be able to compile assets with node 12 and iojs - JS specs still pass Change-Id: Id4a0628ff0c6dd09e622d02329a4400d60459ec2 Reviewed-on: https://gerrit.instructure.com/49493 Tested-by: Jenkins Reviewed-by: Nick Houle <nhoule@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com> QA-Review: Cameron Matheson <cameron@instructure.com>
2015-02-26 06:28:11 +08:00
"karma-firework-reporter": "~0.2.4",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-junit-reporter": "^1",
Update yarn.lock with newest versions of deps closes: CNVS-38384 This is just to keep our tooling up to date Test plan: * automated tests should pass * build tooling should work (meaning webpack builds In prod & dev) Change-Id: I11fbda35827487e59712c762a71540a51258d1db Reviewed-on: https://gerrit.instructure.com/120434 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 01:29:52 +08:00
"karma-qunit": "~1.2.1",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-sourcemap-loader": "^0.3",
publish jUnit test result file from karma tests Test plan: * run `yarn test` * there should be xml file in coverage-js/karma-test-results.xml With the spec results that we will use for Jenkins builds Change-Id: Ic68de197d2b52dbccdf58dc2d148aef1f2ca2646 Reviewed-on: https://gerrit.instructure.com/135949 Tested-by: Jenkins Reviewed-by: Robert Lamb <rlamb@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 23:21:42 +08:00
"karma-spec-reporter": "^0.0.32",
Update yarn.lock with newest versions of deps closes: CNVS-38384 This is just to keep our tooling up to date Test plan: * automated tests should pass * build tooling should work (meaning webpack builds In prod & dev) Change-Id: I11fbda35827487e59712c762a71540a51258d1db Reviewed-on: https://gerrit.instructure.com/120434 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 01:29:52 +08:00
"karma-verbose-reporter": "^0.0.6",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-webpack": "2.0.6",
"merge-stream": "^1",
"moxios": "^0.4",
"prettier": "^1",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"qunitjs": "^1.14.0",
use node_modules wherever possible closes: CNVS-31787 the only things left in bower are things that are just not avalable on npm because they are so old. we'll have to continue using the bower versions of them, but it's ok since they are mostly old ember stuff that will be ripped out when we finish our react screenreader gradebook also: remove some ember stuff that wasn't being used anymore. nothing was using this stuff test plan: this really does touch a lot of stuff. some things to check out specifically in the prod/optimized requireJS build: (load the page, click around to make sure things work) the screenreader gradebook client_apps: quiz statistics quiz event logging creating a new student group calendar, try all the views (month/agenda/etc) gradebook 2 turn on the new course/user search feature for your account and go to accounts/x and search for a user/course the new react gradebook use tinymce on a page, make sure that both the service and local version of it work Change-Id: I4322a154d289760ab51b92e34dd7fac808b41ba8 Reviewed-on: https://gerrit.instructure.com/93102 Tested-by: Jenkins QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com> Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2016-10-19 01:11:26 +08:00
"react-addons-test-utils": "0.14.8",
move redux-logger from prod deps to devDeps Because nothing should be including or using redux-logger in production, It is safe to move it to devDependencies Test plan: * automated builds should pass Change-Id: Ic532f86a559a748388dc2d6b0481f760debc2ac0 Reviewed-on: https://gerrit.instructure.com/133702 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-23 02:57:48 +08:00
"redux-logger": "2.6.1",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"requirejs": "~2.2.0",
make feature flags for Right To Left layout Closes: CORE-1154 There are 2 feature flags here. One a specific user (internal employees, sales people, contractors, etc) can turn on to see where we are and what would still need to be done. And the other is for an account to be able to turn on to let the users in their account that have their language set to an RTL language (eg: Arabic, Farsi or Hebrew) see the interface in RTL This commit is part of a chain of commits. you'll need to apply the ones that follow-on after this to see most of the actual Right To Left features, this commit is mainly just to create the feature flag. Test plan: * go to your user settings page * you should see a feature option for Force RTL Layout” * it should show that it is “in development” * it should should be hidden: eg: only appears for site admins and not For normal users * turn it on (if you have this checked out along with the others that follow beind this commit) * navigate around canvas, most things on most pages should be RTL * you should be able to get an idea of how much more work and what Kind of changes we’d still need to make to get it 100% * now turn off that user feature flag, and go to your account's settings * turn on the "allow users from RTL languages to see RTL layout" account-level feature flag. * nothing should change for you, it should be LTR like normal * set your language to either Arabic, Farsi or Hebrew * now the interface should all be in right to left. (again, you'll need to have the follow-on commits to this to see all of the RTL changes) * without either of the feature flags turned on, absolutely nothing should be different at all anywhere in the interface. Change-Id: Ia78d86fa46d2d289b1913c5d1340546d7f6c3a1f Reviewed-on: https://gerrit.instructure.com/143891 Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins
2018-03-17 02:25:14 +08:00
"sass-direction": "^1",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"script-loader": "^0.7",
"sinon": "^4",
"style-loader": "^0.20",
"stylelint": "^9",
"through2": "^2",
"webpack": "^3",
"webpack-cleanup-plugin": "^0.5",
"webpack-manifest-plugin": "^1",
"webpack-parallel-uglify-plugin": "^1",
make all locale files agree on short month names fixes CNVS-34165 test plan: - make sure you are running with RAILS_LOAD_ALL_LOCALES=1 for (web and webpack if you are running docker) - change locale to each of es, de, fr, fr-ca, he and pl - create/edit a quiz - in the due date try setting the due date to a day in each month - no need to save - make sure after clicking the day it doesn't change to a different month or year Change-Id: I2da96f80678193e084786d867b27f2944a6e402c Reviewed-on: https://gerrit.instructure.com/119926 Tested-by: Jenkins Product-Review: brian kirkby <bkirkby@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Reviewed-by: brian kirkby <bkirkby@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com>
2017-07-20 23:50:43 +08:00
"xsslint": "0.1.4",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"yaml-loader": "^0.5"
clean up JS tests and integrate karma - js:generate_runner now generates common files to be used by different test runners - js spec file order now shuffled to better expose dependencies - fakeENV now returns two methods: setup and teardown - stock tinymce 3 files are now wrapped for AMD test plan: - tinymce should work the same - js:test rake task should run tests - js:build task should work as normal (using new location of r.js) - test results should successfully send to firework Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2 Reviewed-on: https://gerrit.instructure.com/29297 QA-Review: Shawn Meredith <shawn@instructure.com> Tested-by: Shawn Meredith <shawn@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-01-24 23:58:37 +08:00
},
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"jest-junit": {
"output": "./coverage-js/junit-reports/jest.xml"
},
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"repository": "instructure/canvas-lms",
clean up JS tests and integrate karma - js:generate_runner now generates common files to be used by different test runners - js spec file order now shuffled to better expose dependencies - fakeENV now returns two methods: setup and teardown - stock tinymce 3 files are now wrapped for AMD test plan: - tinymce should work the same - js:test rake task should run tests - js:build task should work as normal (using new location of r.js) - test results should successfully send to firework Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2 Reviewed-on: https://gerrit.instructure.com/29297 QA-Review: Shawn Meredith <shawn@instructure.com> Tested-by: Shawn Meredith <shawn@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-01-24 23:58:37 +08:00
"scripts": {
Move planner under canvas-lms closes: CORE-949 this also upgrades us to use what was on canvas-planner master as of 1pm on 2/1/2018 (specifically 9569cc1) test plan: * canvas planner should work * all automated builds should pass Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2 Reviewed-on: https://gerrit.instructure.com/135947 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 22:39:39 +08:00
"test": "concurrently --names \"packages,jest,karma\" \"yarn test:packages\" \"jest\" \"if [ \"$COVERAGE\" ]; then yarn test:karma; else yarn test:karma:concurrently; fi\"",
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"test:watch": "concurrently --names \"jest,karma\" \"jest --watch .\" \"yarn test:karma:watch\"",
"test:jest": "echo 'this is here just so you know you can use jest, but just use the `jest` cli directly' && jest",
"test:karma": "karma start --single-run",
"test:karma:concurrently": "concurrently --names \"coffee,js1,js2\" \"JSPEC_GROUP=coffee yarn test:karma:headless\" \"JSPEC_GROUP=js1 yarn test:karma:headless\" \"JSPEC_GROUP=js2 yarn test:karma:headless\"",
"test:karma:headless": "karma start --single-run --browsers ChromeHeadlessNoSandbox",
"test:karma:watch": "karma start",
"test:karma:watch:headless": "karma start --browsers ChromeHeadlessNoSandbox",
Put finishing touches on planner under canvas - update README with new instructions - update how canvas runs sub-package tests - remove planner's test server closes ADMIN-742 test plan: - when jenkins runs, check to see that planner's tests run too Change-Id: I2493b65f580c76b28f225f1330e99e1ceb1378b4 Reviewed-on: https://gerrit.instructure.com/139882 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> QA-Review: Jon Willesen <jonw+gerrit@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-02-06 02:59:45 +08:00
"test:packages": "script/local-yarn test",
move canvas-rce to canvas-lms/packages/canvas-rce closes CORE-994 refs RECNVS-398 refs CORE-1224 closes CORE-1237 test plan: - yarn install - smoke test rce - tests pass Change-Id: Ieaff024fa89879fac3e7edf99381f46de921cce2 Reviewed-on: https://gerrit.instructure.com/145671 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-04-03 05:52:07 +08:00
"preinstall": "script/uncache-packages && script/local-yarn install && script/local-yarn build:canvas",
make npm build scripts more user friendly :) test plan: - run the following commands and assess that they run as expected: - yarn run build - yarn run build:css - yarn run build:css:watch - yarn run build:js - yarn run build:jss:watch Change-Id: I4c0a2a68ce62896364bc2da5e7956002c15f5847 Reviewed-on: https://gerrit.instructure.com/110497 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2017-05-03 00:44:54 +08:00
"build": "yarn run build:css && yarn run build:js",
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"build:watch": "concurrently \"yarn build:css:watch\" \"yarn build:js:watch\"",
make npm build scripts more user friendly :) test plan: - run the following commands and assess that they run as expected: - yarn run build - yarn run build:css - yarn run build:css:watch - yarn run build:js - yarn run build:jss:watch Change-Id: I4c0a2a68ce62896364bc2da5e7956002c15f5847 Reviewed-on: https://gerrit.instructure.com/110497 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2017-05-03 00:44:54 +08:00
"build:css": "brandable_css",
"build:css:watch": "brandable_css --watch",
"build:js": "yarn run webpack-development",
"build:js:watch": "yarn run webpack",
Move planner under canvas-lms closes: CORE-949 this also upgrades us to use what was on canvas-planner master as of 1pm on 2/1/2018 (specifically 9569cc1) test plan: * canvas planner should work * all automated builds should pass Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2 Reviewed-on: https://gerrit.instructure.com/135947 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 22:39:39 +08:00
"build:packages": "script/yarn-packages build",
Ensure code sent to browsers is es5 …so it works in safari10 & IE11 Closes: CORE-1280 test plan: * run yarn * go into a file in node_modules that is used in a webpack bundle (Eg: node_modules/react-dom/index.js) and change a `var` to a `const` or a `let` and a `function` to an arrow () => function. * run `yarn webpack-production` * it should fail with errors Change-Id: Ic1589d3c1cc266eb5be22cb4716465818d0e98b6 Reviewed-on: https://gerrit.instructure.com/146496 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-04-11 00:36:43 +08:00
"lint:browser-code": "es-check es5 ./public/dist/**/*.js",
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
"webpack": "gulp rev & webpack --progress --color --watch",
"webpack-development": "gulp rev & webpack --progress --color",
Ensure code sent to browsers is es5 …so it works in safari10 & IE11 Closes: CORE-1280 test plan: * run yarn * go into a file in node_modules that is used in a webpack bundle (Eg: node_modules/react-dom/index.js) and change a `var` to a `const` or a `let` and a `function` to an arrow () => function. * run `yarn webpack-production` * it should fail with errors Change-Id: Ic1589d3c1cc266eb5be22cb4716465818d0e98b6 Reviewed-on: https://gerrit.instructure.com/146496 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-04-11 00:36:43 +08:00
"webpack-production": "NODE_ENV=production gulp rev && node --max_old_space_size=4096 $(yarn bin)/webpack --color --config webpack.production.config.js && yarn lint:browser-code",
add npm script that can run specific js specs example usage: `npm run jspec spec/javascripts/jsx/files` refs CNVS-33223 test plan: - current webpack test build should work exactly the same - `npm run jspec` should build + run all specs - `npm run jspec path/to/stuff` should build + run only specified specs - should work with both directories and individual files - `jspec-watch` should watch + build a path, but not run specs Change-Id: I788dd38a6c69a4c36a1300fcecf43678bc7f5327 Reviewed-on: https://gerrit.instructure.com/94625 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> QA-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2016-11-08 05:13:53 +08:00
"jspec": "./spec/jspec.sh",
spec: add aXe unit testing capability this patch updates the a11y helper, adds a new spec script to run, and adds aXe testing to discussion views test plan: - run the spec files edited in this patch normally with yarn run jspec-watch path/to/spec - tests should all pass as expected - run the spec files edited in this patch with the new command yarn run a11y-report path/to/spec - you should get aXe errors on existing a11y violations Change-Id: Ib3db892046e115bedb363752d1e56226eef893af Reviewed-on: https://gerrit.instructure.com/87962 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Matt Berns <mberns@instructure.com> QA-Review: Matt Berns <mberns@instructure.com>
2016-08-17 05:30:29 +08:00
"jspec-watch": "./spec/jspec.sh --watch",
script to upgrade without adding dupes to yarn.lock because yarn is silly and frequently adds duplicate entries for things into yarn.lock when it could satisfy everything the app needs with one version; when you make any changes to package.json, run this script: `yarn upgrade-and-dedupe` to make sure that yarn.lock doesn't add needless duplicates of things. if yarn ever fixes this issue: https://github.com/yarnpkg/yarn/issues/579 then this can go away. test plan: 1. check this out 2. run `yarn upgrade-and-dedupe` 3. push the change that commit makes 4. it should pass jenkins and not introduce any errors Change-Id: I8c268cc4c7c6ac4474221ce65129a6ef8b261813 Reviewed-on: https://gerrit.instructure.com/142447 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-03 02:20:00 +08:00
"a11y-report": "./spec/jspec.sh --a11y",
"upgrade-and-dedupe": "rm -rf yarn.lock node_modules && yes 1 | yarn install --flat --production && git checkout package.json && yarn install && git add yarn.lock && git commit -m 'update npm deps'"
make it so it works with yarn 1.3.2 (frd) closes: CORE-675 test plan: * while running yarn 0.27, * run `yarn` * it should work and there should only be one jquery in node_modules * brew upgrade yarn (or whatever else you do to upgrade yarn to 1.3.2) * run `yarn` * it should not log any warning about unpacking jquery to the same location as something else * it should work and not make any changes to yarn.lock or node_modules * load the calendar page, there should not be any errors Change-Id: I08a1b8ceddf31cae59720270f870516ad213b87d Reviewed-on: https://gerrit.instructure.com/133548 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-22 07:09:15 +08:00
},
"resolutions": {
Add DateTimeInput to planner The user can now enter a due date and time. refs ADMIN-297 test plan: - load the planner - create a new to do > expect the time to default to 11:59pm - save > expect the due time of 11:59 to be shown in the planner - edit the item, change the time, save > expect the new time to show up in the planner - edit the item, delete the date, tab out of the date text box > expect a "you must provide a date and time" error message > expect the Save button to be disabled - pick a date > expect the error message to go away - save > expect the to do to be in the planner at the given date and time Change-Id: I6759cca675b59acfc200574a1e313f75e1cfda2e Reviewed-on: https://gerrit.instructure.com/145147 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com> Product-Review: Christi Wruck
2018-03-29 03:43:24 +08:00
"jquery": "https://github.com/ryankshaw/jquery.git#a755a3e9c99d5a70d8ea570836f94ae1ba56046d",
"moment": "2.10.6"
AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
}
move canvas-rce to canvas-lms/packages/canvas-rce closes CORE-994 refs RECNVS-398 refs CORE-1224 closes CORE-1237 test plan: - yarn install - smoke test rce - tests pass Change-Id: Ieaff024fa89879fac3e7edf99381f46de921cce2 Reviewed-on: https://gerrit.instructure.com/145671 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-04-03 05:52:07 +08:00
}