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

273 lines
10 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": {
relax node version req so it works w/ docker Test plan: * if you rebuild your docker image it shouldn’t complain about A node version that is not compatible with this module Change-Id: Ieef58139be7a913a9aa3b5156937e01752dd1537 Reviewed-on: https://gerrit.instructure.com/186683 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-25 22:45:33 +08:00
"node": ">=10.14.0",
Bump to Node 10 closes CORE-2329 There were some tests that were expecting a snapshot-like value where it expected `new Date().toLocaleDateString()` to give something Like “2016-7-11” but that was actually wrong. If you do `new Date().toLocaleDateString()` in a browser it will give you something like “7/11/2016”. And this new version of node matches what a real browser would have done, so I just updated the specs so they are looking for the correct format. This change does not actually reflect a change in what a real user would see. Just what jest/jsdom/node formats it as. Test Plan: - check to make sure that the assignments 2 availability dates component produces markup exactly as it did before - Automated tests pass - Build canvas locally, everything passes. - Build canvas with docker, everything passes. Change-Id: I74285cd6d9b251ca60ab79396e332cc3a419bcee Reviewed-on: https://gerrit.instructure.com/177198 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-01-09 04:25:49 +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
},
Use yarn workspaces Run `script/nuke_node.sh` to clean everything up Run `yarn install` it should install everything for everything Run `yarn build` and `yarn test` they should work exactly as before Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146 Reviewed-on: https://gerrit.instructure.com/151356 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-05-25 00:09:03 +08:00
"private": true,
"workspaces": {
"packages": [
spec: increase the timeout of canvas-rce specs Also: * update mocha-jsdom to eliminate a spec issue * fix some specs test plan: * Verify Jenkins passes Change-Id: Ib486336306719b5ca4160e15843a0aac084c5c92 Reviewed-on: https://gerrit.instructure.com/153972 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-06-15 22:04:23 +08:00
"gems/canvas_i18nliner",
"gems/selinimum",
treat anything in gems/plugins/* as a workspace Fixes: https://github.com/instructure/canvas-lms/issues/1323 This lets open source users continue putting their own plugins with npm deps In gems/plugins. They will still have to have a forked version Of yarn.lock though since that will be different for them than a “Default” install. Also, this means that everyone will see a bunch of warnings like this Every time they yarn install: Warning: gems/plugins/academic_benchmark is a dir… no package.json Warning: gems/plugins/account_reports is a dir.. has no package.json Warning: gems/plugins/canvas_geoip is a …, but has no package.json Warning: gems/plugins/demo_site is a directory, but has no package.json Warning: gems/plugins/instructure_misc_plugin is … has no package.json Warning: gems/plugins/moodle_importer is a d.., but has no package.json Warning: gems/plugins/qti_exporter is a dir…, but has no package.json Warning: gems/plugins/respondus_soap_endpoint is … no package.json Warning: gems/plugins/simply_versioned is a …, but has no package.json Test plan: * yarn install should work Change-Id: Ie65c8faf8b1022210cfb7eda8c25107facfe83b5 Reviewed-on: https://gerrit.instructure.com/158043 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-07-20 03:42:35 +08:00
"gems/plugins/*",
Use yarn workspaces Run `script/nuke_node.sh` to clean everything up Run `yarn install` it should install everything for everything Run `yarn build` and `yarn test` they should work exactly as before Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146 Reviewed-on: https://gerrit.instructure.com/151356 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-05-25 00:09:03 +08:00
"packages/*",
"client_apps/*"
],
"nohoist": [
"canvas_quizzes/grunt*",
"canvas_quizzes/jasmine*"
]
},
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": {
upgrade instUI to 5.33.0 Refs COMMS-1522 Test Plan: * Jenkins passes Change-Id: I6fd52c80375d10b6cbb69c1146004a9daaf5442c Reviewed-on: https://gerrit.instructure.com/172594 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2018-11-16 04:22:01 +08:00
"@instructure/media-capture": "^5",
bump npm-run-all version Change-Id: Ieae7ac480124e52050c79ca83c99a7fe698c48d5 Reviewed-on: https://gerrit.instructure.com/173262 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Gary Mei <gmei@instructure.com> Product-Review: Gary Mei <gmei@instructure.com>
2018-11-27 02:20:33 +08:00
"@instructure/react-crop": "^5.0.1",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"@instructure/ui-alerts": "^5",
"@instructure/ui-billboard": "^5",
"@instructure/ui-breadcrumb": "^5",
"@instructure/ui-buttons": "^5",
"@instructure/ui-core": "^5",
Make A2 header content editable waiting on an instui release. without it 1. the Points edit has the wrong font size 2. you cannot delete a module closes ADMIN-2303 test plan: - create an assignment, open it, click the assignments 2 button, then add #edit to the url and refresh (this forces the assignment into edit mode) > expect the assignment type to be "Assignment" and to be editable - on selecting any value other than "Assignment", expect to be sent to the corresponding page in canvas after confirmation > expect the correct module(s) to be selected, and to be editable - expect to be able to select > 1 module - when all modules are deleted, expect th "No Module Assigned" placeholder > expect the correct assignment group to be selected, and to be editable > expect the assignment name to be correct and editable - edit and delete the name > expect a "name is required" message > expect the points to be correct and editable - entering anything that's not a number should result in an error message Change-Id: Ief36b01d7f5380f16d3e76b7afeb7d7d8e38b3bc Reviewed-on: https://gerrit.instructure.com/176293 Tested-by: Jenkins Reviewed-by: Carl Kibler <ckibler@instructure.com> QA-Review: Carl Kibler <ckibler@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-12-21 05:30:07 +08:00
"@instructure/ui-editable": "^5",
track anonymous grading in the audit trail ui closes GRADE-1668 test plan: A. Setup 1. Create an assignment * With moderated grading * With anonymous grading * Worth 10 points * Three graders (A, B, and C) * Teachers as final grader (not admin) * Assigned to only one or two students * just for less work in QA 2. As each student, submit to the assignment 3. As Grader A: a. Assign provisional grades b. Maybe leave a submission comment or two 4. As the teacher, disable anonymous grading * The related event will have a warning badge 5. As Grader B: a. Assign provisional grades b. Maybe leave a submission comment or two * The related events will have warning badges 6. As the teacher, re-enable anonymous grading 7. As Grader C: a. Assign provisional grades b. Maybe leave a submission comment or two 8. As the final grader: a. Visit the moderation page b. Select provisional grades c. Post grades d. Display grades to students B. Verify 1. Log in as a user with "view audit trail" permission (admin) 2. Open the assignment in SpeedGrader 3. Open the assessment audit trail 4. For Grader A a. Expand the user event group for Grader A b. Verify there is no non-anonymous warning icon to the side of the user name c. Verify there are no non-anonymous warning badges to the side of the user's grading actions 5. For Grader B a. Expand the user event group for Grader B b. Verify there is a non-anonymous warning icon to the side of the user name c. Verify the non-anonymous warning icon triggers a sensible tooltip d. Verify there are some non-anonymous warning badges to the side of the user's grading actions e. Verify the badged icons trigger sensible tooltips 6. For Grader C a. Expand the user event group for Grader C b. Verify there is no non-anonymous warning icon to the side of the user name c. Verify there are no non-anonymous warning badges to the side of the user's grading actions 7. For the teacher a. Expand the user event group for the teacher b. Verify there is a non-anonymous warning icon to the side of the user name c. Verify there is a non-anonymous warning badge to the side side of the user's action disabling anonymous grading d. Verify there are no non-anonymous warning badges to the side of the user's moderation actions (after enabling anonymous) Change-Id: I2e675b84dc3e6b59e3111ed39b7a814f38f19f5c Reviewed-on: https://gerrit.instructure.com/170684 Tested-by: Jenkins Reviewed-by: Gary Mei <gmei@instructure.com> Reviewed-by: Adrian Packel <apackel@instructure.com> QA-Review: Adrian Packel <apackel@instructure.com> Product-Review: Sidharth Oberoi <soberoi@instructure.com>
2018-11-01 22:13:35 +08:00
"@instructure/ui-focusable": "^5",
Add override details to teacher view closes ADMIN-1510 This change includes some code to flip some of the elements into edit mode, but that's not part of this ticket (though if you want to see it, add #edit to the URL) test plan: - have an assignment with some submission types, specified allowed filename extensions, due, lock, unlock dates - load /courses/:course_id/assignments/:assignmen_id?assignments_2=true - click the ">" to expand the override summary to see the details > expect the data to match your assignment notes: - "score to keep" and submission requirements are hard-coded for now until we get the data - the attempts input only appears when attempts allowed is limited (e.g. non null) - Submission Requirement only appears when there are > 1 submission types - the UI mostly matches the mockup. Mary's design is changing, so it may not be 100% exact. Change-Id: Ia385ec7880e3d834658d412a4c7ac5afc9091fac Reviewed-on: https://gerrit.instructure.com/175098 Tested-by: Jenkins QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com> Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com>
2018-12-12 06:06:18 +08:00
"@instructure/ui-form-field": "^5",
dynamic import comments refs COMMS-1844 Test Plan: - Click on comments on an A2 student view - notice there is a loading indicator then the comments load Change-Id: I43ed778b826153b5cb4e58b9365a0016dec10897 Reviewed-on: https://gerrit.instructure.com/180618 Tested-by: Jenkins Reviewed-by: Aaron Hsu <ahsu@instructure.com> QA-Review: Landon Gilbert-Bland <lbland@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2019-02-06 04:54:30 +08:00
"@instructure/ui-forms": "^5",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"@instructure/ui-icons": "^5",
"@instructure/ui-layout": "^5",
"@instructure/ui-menu": "^5",
Make A2 header content editable waiting on an instui release. without it 1. the Points edit has the wrong font size 2. you cannot delete a module closes ADMIN-2303 test plan: - create an assignment, open it, click the assignments 2 button, then add #edit to the url and refresh (this forces the assignment into edit mode) > expect the assignment type to be "Assignment" and to be editable - on selecting any value other than "Assignment", expect to be sent to the corresponding page in canvas after confirmation > expect the correct module(s) to be selected, and to be editable - expect to be able to select > 1 module - when all modules are deleted, expect th "No Module Assigned" placeholder > expect the correct assignment group to be selected, and to be editable > expect the assignment name to be correct and editable - edit and delete the name > expect a "name is required" message > expect the points to be correct and editable - entering anything that's not a number should result in an error message Change-Id: Ief36b01d7f5380f16d3e76b7afeb7d7d8e38b3bc Reviewed-on: https://gerrit.instructure.com/176293 Tested-by: Jenkins Reviewed-by: Carl Kibler <ckibler@instructure.com> QA-Review: Carl Kibler <ckibler@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-12-21 05:30:07 +08:00
"@instructure/ui-number-input": "^5",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"@instructure/ui-overlays": "^5",
"@instructure/ui-pagination": "^5",
A2: search and sort on teacher view students tab closes ADMIN-2510 test plan: - on the students tab of teacher view: - type in the search field, at least 3 characters - the search should happen after a short delay and display results - the name, score, and submission date columns are sortable in ascending and descending order - sorting causes another load - enter less than 3 characters in the search field - after a short delay, a message should be displayed about needing 3 characters - clearing the search field should go back to original search of all students Change-Id: Ibaaeff175089003a4a5fcbb27db32c9510330e25 Reviewed-on: https://gerrit.instructure.com/186995 Tested-by: Jenkins Reviewed-by: Ed Schiebel <eschiebel@instructure.com> QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Jon Willesen <jonw+gerrit@instructure.com>
2019-03-22 01:32:00 +08:00
"@instructure/ui-table": "^5",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"@instructure/ui-tabs": "^5",
"@instructure/ui-themeable": "^5",
"@instructure/ui-themes": "^5",
"@instructure/ui-toggle-details": "^5",
use apollo client instead of apollo boost This prepares us for using apollo's instrospection fragment matcher (which isn't supported with -boost). Test plan: pages that use graphql still work refs GQL-17 Change-Id: Ib6af304855e6c0e23b598344ac1d30f4d4aa03a5 Reviewed-on: https://gerrit.instructure.com/172936 Tested-by: Jenkins Reviewed-by: Carl Kibler <ckibler@instructure.com> QA-Review: Cameron Matheson <cameron@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com>
2018-11-20 04:17:17 +08:00
"apollo-cache-inmemory": "^1.3.10",
"apollo-client": "^2.4.6",
"apollo-link": "^1.2.3",
"apollo-link-error": "^1.1.1",
"apollo-link-http": "^1.5.5",
Display multiple modules in A2 student view This also adds support for apollo-link-state. We are using this to move data from the `ENV` into our apollo query results, to keep a single source of truth and easier unit tests. If there are more then two modules that an assignment belongs to (which is abnormal) we are only rendering the first two modules with an additional link to the modules page, indicating that there are more modules this assignment belongs to. Fixes COMMS-1800 Test Plan: - Create an assignment, and add it to four modules - Navigate to the assignment as a student - Notice that 2 of the four modules are displayed in the header Change-Id: I9b797486ba56c8b827e5f76114c5a08d2f969f41 Reviewed-on: https://gerrit.instructure.com/174837 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Landon Gilbert-Bland <lbland@instructure.com> Product-Review: Landon Gilbert-Bland <lbland@instructure.com>
2018-12-11 03:56:24 +08:00
"apollo-link-state": "^0.4.2",
Upgrade axios from 0.16 to 0.18 This is so all of our pages that use axios can share the same one Test plan: * the selenium tests, which test pages using axios, should pass. Change-Id: I24d15fb7fa282891b80fadb91d06d9dfa019b5d1 Reviewed-on: https://gerrit.instructure.com/155300 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-06-27 02:56:45 +08:00
"axios": "^0.18.0",
Add sub-account settings for CSP closes CORE-2253 Test Plan: - Enable CSP settings - Go to a sub-account's settings page - You should see a security tab - Go to the security tab - CSP information should be displayed including a toggle between Off, Inherited, and On. - Behavior should match the description shown on the page. Change-Id: If2a485cc3712f6af8d266401da67d4deaa845696 Reviewed-on: https://gerrit.instructure.com/177971 Tested-by: Jenkins QA-Review: Tucker Mcknight <tmcknight@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2019-01-16 02:40:26 +08:00
"axios-cache-adapter": "^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
"backbone": "1.1.1",
maintain precision of grades in grade input fixes GRADE-1098 test plan: 1. Create an Assignment a. with Display Grade as Percentage b. worth 9.5 points 2. Open New Gradebook 3. Grade a student on this assignment twice a. once with 55 (interpreted as percentage) b. again with 55% (explicit percentage) 4. Verify grade is 55% 5. Verify score is 5.225 Change-Id: Ie48ec7d5b787e864bfd3379e8dc6a4dbebebc2e5 Reviewed-on: https://gerrit.instructure.com/148848 Tested-by: Jenkins Reviewed-by: Derek Bender <djbender@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: Shahbaz Javeed <sjaveed@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com>
2018-05-02 04:54:56 +08:00
"big.js": "^5.0.3",
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",
Use yarn workspaces Run `script/nuke_node.sh` to clean everything up Run `yarn install` it should install everything for everything Run `yarn build` and `yarn test` they should work exactly as before Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146 Reviewed-on: https://gerrit.instructure.com/151356 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-05-25 00:09:03 +08:00
"canvas-planner": ">=1.0.16",
Bump @instructure/canvas-rce-old to 4.1.2 closes CORE-2712 Test Plan: - Automated tests pass Change-Id: I7ea688ed7fba1212f74676a0f52784e32b80baae Reviewed-on: https://gerrit.instructure.com/187345 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-29 00:34:44 +08:00
"@instructure/canvas-rce-old": "4.1.2",
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",
react 16: use createReactClass for things that can’t be es6 classes these components can’t be converted to the react es6 class syntax because they use Mixins which aren’t supported by es6 classes. Change-Id: I8541b08518cd335c7a711bab117efcda65ac6b2c Reviewed-on: https://gerrit.instructure.com/164135 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-09-12 13:29:44 +08:00
"create-react-class": "^15.6.3",
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",
Add graphiql-explorer to canvas' graphiql instance The graphiql-explorer makes it easy to explore the schema and build queries simply by checking the boxes next to fields from the schema test plan: - /graphiql still works as expected, but includes the explorer panel - canvas features that leverage graphql still work as expected (since the version of the graphql js client was updated) Change-Id: Ief625c6fb59e4e32e23a177f3b566aae271ab108 Reviewed-on: https://gerrit.instructure.com/181586 Tested-by: Jenkins Reviewed-by: Carl Kibler <ckibler@instructure.com> QA-Review: Carl Kibler <ckibler@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2019-02-13 23:29:15 +08:00
"graphiql-explorer": "^0.3.6",
"graphql": "^14",
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-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",
Update assignment as it's edited closes ADMIN-2343 test plan: - load an assignment in the A2 teacher view, add #edit to the url and refresh the page - change each field on the page (modules, group, name, points, description, submission type, attempts allowed. others are not wired up yet since the UI for these either isn't built yet, or has changed recently) > expect the Cancel/Save/Publish foot er to appear. buttons on the right > on clicking cancel, expect the changed value(s) to revert and the footer to disappear > on clicking save, expect the footer to disappear > on clicking publish, if previously unpublished expect footer to disappear and the toggle to flip to published - flip the publish toggle > expect the footer _not_ to appear - flip to rtl > expect the footer buttons to be on the left, even in Edge - enter an invalid value for Points > expect an error message, and for the field to remain in edit mode - delete the assignment's name and TAB > expect an error message that the name is required Disabling the Save and Publish buttons when there are invalid fields on the page is left to ADMIN-2443 Change-Id: I016af6dc6e0e18d9aed1c364a328f9107a4d2762 Reviewed-on: https://gerrit.instructure.com/180831 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2019-02-07 06:39:27 +08:00
"immer": "^2.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
"immutability-helper": "^2",
Configurable proficiency ratings page closes OUT-1856, OUT-1858, OUT-2239, OUT-2148 This adds configurable proficiency ratings on the account rubrics page. Persisting these changes will occur in a future patchset (2252). Validating order will be in a separate patchset (2240). test plan: - with the "non-scoring rubrics" feature flag off, the account rubrics page should appear without the proficiency ratings tab - with the "non-scoring rubrics" feature flag on, the accounts rubrics page should appear with the proficiency tab, if visiting with an account with "manage_outcomes" permission (e.g. account admin) - create an account role that has "Create and edit assessing rubrics" permission enabled but "Manage learning outcomes" disabled by going to the account page, click on the "Permissions" link in the left menu, then select the "Account Roles" tab to then be able create the role and enable the permission above. - create an account user by going to the account page and then click on the "People" link in the left menu to then be able to click on "+ New User". you'll use the email address entered in the next step. - make that user an account admin by going to the account page, click on the "Settings" link in the left menu, then select the "Admins" tab, then click on "+ Account Admins". select the new role from the drop down menu and enter the email address you used in the preivous step - confirm with the feature flag enabled, that visiting the account rubrics page does not appear with the proficiency tab, if visiting with an account without "manage_outcomes" permission (e.g. masquerade as the user created above) - on the proficiency tab, test error handling: * description is required * points is required, should be a valid number * when saving changes, all fields with errors should be labelled with an error text, with the first field receiving focus Change-Id: Ic52ef9fe9c58cfb215216b3a505ef1fb4b851c68 Reviewed-on: https://gerrit.instructure.com/150841 Reviewed-by: Michael Brewer-Davis <mbd@instructure.com> Reviewed-by: Frank Murphy <fmurphy@instructure.com> Tested-by: Jenkins QA-Review: Dariusz Dzien <ddzien@instructure.com> Product-Review: Sidharth Oberoi <soberoi@instructure.com>
2018-04-10 09:20:00 +08:00
"immutable": "^3.8.2",
Add CSP whitelist to the security settings closes CORE-2109 Test Plan: - Enable the Content Security Policy feature flag - Go to account settings, security tab - Use the Add Domain form to add a domain - It should appear on the whitelist - Flip the CSP switch to enabled Change-Id: Iaea578c52e9b8bb6541a4e13edc6a1702e907cdf Reviewed-on: https://gerrit.instructure.com/174980 Tested-by: Jenkins QA-Review: Tucker Mcknight <tmcknight@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
2018-12-11 13:51:31 +08:00
"is-valid-domain": "^0.0.6",
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",
Fix XSS in calander Fixes COMMS-1846 Test Plan: * Go to the calendar, click on a day to add an event, and click on the "More Options" button. * Switch to the html editor, and add the following: <img class='equation_image' data-mathml='<img src=x onerror=prompt(document.cookie); />'> * Save the event. Go back to the calendar and click on the newly saved event, and notice that you don't get XSS'd * Create another event in the calendar, and this time add the following via the html editor: <img class="equation_image" title="(-\infty,\infty)" src="/equation_images/(-%255Cinfty%252C%255Cinfty)" alt="Infinities: (-\infty,\infty)" data-equation-content="(-\infty,\infty)" /> * Save the event, and load it in the calendar. Notice that it still properly displays this mathml image properly. * Test the same calendar event with a screen reader, and notice that it is still accessible Change-Id: If0f1ac8ad93f04ececb7aa2f7ef221204b1ce14f Reviewed-on: https://gerrit.instructure.com/179783 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Landon Gilbert-Bland <lbland@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2019-01-30 00:34:54 +08:00
"mathml-tag-names": "^2.1.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
"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",
Pass correct locale to Planner Sometimes ENV.LOCALE and ENV.MOMENT_LOCALE are different (zh-Hans v zh-cn or mi v mi-nz). We were passing the former to planner, but moment needs the full locale, including language and region identifiers, and formatMessage copes with the full locale just fine, so we really need to pass in the latter or moment eventually blows up. So mi-nz month names would successfully parse, had to both bump our version of moment and tweak the canvas customized mi-nz locale data. to test, you'll have to run yarn to update moment, then build with RAILS_LOAD_ALL_LOCALES=1 yarn build Note on the changes to timezoneSpec.js: - some of the specs were parsing dates like "Mon, Aug 3", which are being interpreted in the current year, when Aut 3 is not a Monday. Resolved this by using MockDate to pretend today is 2/1/2015 - moment does not always interpret the Chinese characters for evening as implying PM. I'm assuming canvas will never need that particular construct and commented out the failing string. - there's one date-time that's getting the date totally wrong. - Fixed grammatically incorrect instances of '8月 3, 2015' to ''8月 3日, 2015' - fix cases where the year is coming after the month and day, which would never really happen fixes ADMIN-1331 test plan: - have a student in course so planner is enabled. - go to /profile/settings and Edit - change the Language to Reo Māori (Aotearoa) and "Update Settings" - go to the planner dashboard - click on + to create a new todo > expect you can create a todo. If you want, you can repeat with any of the languages listed in the ticket just to prove ^that wasn't a fluke. Change-Id: I9ba069ef61529088ab92271d7857998df6bbc409 Reviewed-on: https://gerrit.instructure.com/161206 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Reviewed-by: Mysti Sadler <mysti@instructure.com> Reviewed-by: Jeremy Stanley <jeremy@instructure.com> QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-08-18 03:21: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",
Put parse-link-header back in package.json …since we use it in our code It used to be there, but somehow someone deleted it on accident Change-Id: Id516fdb8507887ffed9450869654fc42a4afc415 Reviewed-on: https://gerrit.instructure.com/151898 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-05-31 02:03:31 +08:00
"parse-link-header": "^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
"prop-types": "^15",
update qs dependency test plan: * Verify Jenkins passes? Change-Id: If472d2f898e4241d0d10dfd7f1ca5094ecf9d811 Reviewed-on: https://gerrit.instructure.com/184039 Tested-by: Jenkins Reviewed-by: KC Naegle <knaegle@instructure.com> Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Jeremy Neander <jneander@instructure.com>
2019-03-07 00:43:35 +08:00
"qs": "^6.6.0",
Bump react to 16.6 closes CORE-2037 Change-Id: I1c00623f789a3a5e377fb0529144a6ebd84a1546 Reviewed-on: https://gerrit.instructure.com/169535 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-10-24 22:12:06 +08:00
"react": "^16.6.0",
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",
Upgrade react-dnd so it works w/ react 16 Closes: CORE-1871 The react-dnd commit that first added react 16 to its peerDeps (https://github.com/react-dnd/react-dnd/commit/c6123fad317) First appeared in v2.5.2 so we need at least that version If we are going to use react 16 Test plan: * dashboard card and discussion reordering should still work like they always have Change-Id: I74b47949f3d0f7084c350d24a8de41139f535732 Reviewed-on: https://gerrit.instructure.com/164071 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-09-12 05:22:47 +08:00
"react-dnd": "^2.5.2",
"react-dnd-html5-backend": "^2.5.2",
Bump react to 16.6 closes CORE-2037 Change-Id: I1c00623f789a3a5e377fb0529144a6ebd84a1546 Reviewed-on: https://gerrit.instructure.com/169535 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-10-24 22:12:06 +08:00
"react-dom": "^16.6.0",
fix expand/contract all buttons in new sLMGB closes OUT-2232 Test plan: - enable non-scoring rubrics - load student LMGB with multiple outcome groups, outcomes, and outcome results - verify that expanding and contracting the groups and outcomes works as expected - verify that after contracting a group and then re-expanding, the outcomes within the group are contracted - verify that the expand all and contract all buttons at the top of the page are enabled and disabled at the appropriate times - expand all: should be enabled when any element is contracted - contract all: should be enabled when any element is expanded - verify that the expand all/contract all buttons work as expected Change-Id: Ifbe02e900459faed8d411afb2bb9410a885a2237 Reviewed-on: https://gerrit.instructure.com/152103 Tested-by: Jenkins Reviewed-by: Matt Berns <mberns@instructure.com> Reviewed-by: Frank Murphy <fmurphy@instructure.com> QA-Review: Dariusz Dzien <ddzien@instructure.com> Product-Review: Sidharth Oberoi <soberoi@instructure.com>
2018-06-01 05:13:10 +08:00
"react-immutable-proptypes": "^2.1.0",
Developer key scopes UI (functioning skeleton) Closes PLAT-3314 Test Plan - Enable new developer key FFs - Navigate to the developer keys page of an account - Verify all scope groups are rendered in the new scopes list component. - Verify the filter allows filtering by scope group name. - Verify the "Read Only GET" checkbox causes all scopes that use GET to be checked. - Go crazy testing checkboxes and make sure they all work logically (i.e. selecting the group level checkbox checks all scopes in the group). - Verify that each group shows a list of methods for all selected scopes. - Verify you can still create developer keys in root accounts and site admin. Change-Id: I5df402ca06740e8a1ff37c21b63d2d6d58720182 Reviewed-on: https://gerrit.instructure.com/149242 Reviewed-by: Marc Alan Phillips <mphillips@instructure.com> Tested-by: Jenkins QA-Review: August Thornton <august@instructure.com> Product-Review: Jesse Poulos <jpoulos@instructure.com>
2018-04-27 04:24:36 +08:00
"react-lazy-load": "^3.0.13",
Upgrade react-modal so it works with react 16 I know I said that the way forward was to just not use react-modal and use instUI modal instead but there are a bunch of things that _are_ Using it and I don’t want changing all those to be blockers for react16 if this will work. I still want us to get rid of react-modal, just don’t want it to be a blocker for react 16 Test plan: Things that use react-modal should still work the same as before. Check: * the color picker used on the calendar sidebar * the external apps stuff that has modals * the file preview modal in files * the “find appointment” modal in scheduler Change-Id: I606eda110782cd3300fcbb2f8052681fa5048050 Reviewed-on: https://gerrit.instructure.com/164232 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-09-13 03:05:43 +08:00
"react-modal": "^3",
add media player to submission comments fixes COMMS-1867 Test Plan: - In old assignments/submission works flow add a couple comments that are either video only or audio only - in A2 as a student visit the comments tab - notice the videos show up in the new player and work as expected Change-Id: Ibbb87dd6e264fe49431045e3365771b21111134c Reviewed-on: https://gerrit.instructure.com/185633 Reviewed-by: Ryan Norton <rnorton@instructure.com> Tested-by: Jenkins QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2019-03-17 03:45:57 +08:00
"react-player": "^1.9.3",
Update react-redux to 5.1.1 test plan: - automated tests pass Change-Id: I6c1034ec8f443d10d39b5b551c1b7207e5191411 Reviewed-on: https://gerrit.instructure.com/173814 Tested-by: Jenkins Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com>
2018-11-30 08:54:31 +08:00
"react-redux": "^5.1.1",
upgrade react-token-input so it supports react 16 closes: CORE-1885 Test plan: * make sure the token input that appears when you edit assignment due date Overrides on the assignment overrides page still works Like it did before. Here’s it’s original test plan: new due dates selection UI - on assignments, quizzes & discussions pages - with DA on and off - assign various due dates/(un)lock dates to source sections, individuals, and everybody - these should create overrides that properly take students/sections and dates - validations should work for all dates as normal and not let empty overrides get created (with no students or sections) - the names of overrides should properly update as students change - as more overrides get created, saving assignments should not slow down significantly - the student/section selector should be intuitive * the “new grading period set” form should work as it did before. Here’s it’s original test plan: A new button "+ Add Grading Period Set" is on the Grading Period Sets page. This allows a new set to be named and associated with as many terms as needed. To begin, visit the Grading page for an account (e.g. /accounts/1/grading_standards) and click "+ Set of Grading Period" and within this form ensure the following: 1. Given no name in the "Set name" field, when clicking the "Create" button a flash message is displayed and the set is not saved 2. Given no enrollment terms in the "Attach terms", when clicking the "Create" button a flash message is displayed and the set is not saved 3. Given a name and at least one attached enrollment term, when clicking the "Create" button an AJAX call successfully persists to the database and the new set is displayed on the page along with a successful flash message 4. When the form is open, the "+ Set of Grading Periods" button is disabled 5. When the form is in the process of creating a new set, the "Create" and "Cancel" button is disabled 6. Clicking close at any other time closes the form and re-enables the "+ Set of Grading Periods" button and all data in the form is cleared Change-Id: Ibb0290202b5dcf00ec42a4bb6d1c3d2e3d7a3b2b Reviewed-on: https://gerrit.instructure.com/164492 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-09-14 23:20:08 +08:00
"react-tokeninput": "^2.5.0",
bump npm-run-all version Change-Id: Ieae7ac480124e52050c79ca83c99a7fe698c48d5 Reviewed-on: https://gerrit.instructure.com/173262 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Gary Mei <gmei@instructure.com> Product-Review: Gary Mei <gmei@instructure.com>
2018-11-27 02:20:33 +08:00
"react-transition-group": "^1",
Update redux to 4.0.1 test plan: - automated tests pass Change-Id: I00260366f32e0407eaf4277b5b2d26d9896915ac Reviewed-on: https://gerrit.instructure.com/173813 Tested-by: Jenkins Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com>
2018-11-30 08:52:22 +08:00
"redux": "^4.0.1",
Update redux-actions to 2.6.4 test plan: - automated tests pass Change-Id: I82969f661e78370c8a2f9035c2bca7d2397fb377 Reviewed-on: https://gerrit.instructure.com/173815 Tested-by: Jenkins Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com>
2018-11-30 08:57:55 +08:00
"redux-actions": "^2.6.4",
Update redux-thunk to 2.3.0 test plan: - automated tests pass Change-Id: I3417cc46a9581dd4fe72fc96f8c8e995b90303fd Reviewed-on: https://gerrit.instructure.com/173816 Tested-by: Jenkins Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com>
2018-11-30 09:00:13 +08:00
"redux-thunk": "^2.3.0",
Fix XSS in calander Fixes COMMS-1846 Test Plan: * Go to the calendar, click on a day to add an event, and click on the "More Options" button. * Switch to the html editor, and add the following: <img class='equation_image' data-mathml='<img src=x onerror=prompt(document.cookie); />'> * Save the event. Go back to the calendar and click on the newly saved event, and notice that you don't get XSS'd * Create another event in the calendar, and this time add the following via the html editor: <img class="equation_image" title="(-\infty,\infty)" src="/equation_images/(-%255Cinfty%252C%255Cinfty)" alt="Infinities: (-\infty,\infty)" data-equation-content="(-\infty,\infty)" /> * Save the event, and load it in the calendar. Notice that it still properly displays this mathml image properly. * Test the same calendar event with a screen reader, and notice that it is still accessible Change-Id: If0f1ac8ad93f04ececb7aa2f7ef221204b1ce14f Reviewed-on: https://gerrit.instructure.com/179783 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Landon Gilbert-Bland <lbland@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2019-01-30 00:34:54 +08:00
"sanitize-html": "^1.20.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
"spin.js": "2.3.2",
"swfobject": "^2.2.1",
"tablesorter": "^2.28.5",
bump bigeasy/timezone to 1.0.18 (2018e) fixes CORE-1985 Change-Id: Ia9d5eddf1462de2226e43012f4756fc1f9b93c25 Reviewed-on: https://gerrit.instructure.com/168277 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Cody Cutrer <cody@instructure.com> Product-Review: Cody Cutrer <cody@instructure.com>
2018-10-16 01:36:11 +08:00
"timezone": "^1.0.18",
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",
upgrade tinymce-a11y-cheker to work with tinyMCE 5 Closes: CORE-2727 CORE-2728 CORE-2729 This version works with both 5.x and 4.x of tinymce, so it will be fine To use for both the old code and the new code Test plan: * smoke test to make sure that the a11y checker works just like it used to * in my following commit that upgrades to tinymce 5, you should not see Errors about the a11y_checker plugin not working with tinymce 5 Change-Id: I220e79a5c5e04fc589d906adde83ab4c7ebb5794 Reviewed-on: https://gerrit.instructure.com/188187 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2019-04-04 01:31:39 +08:00
"tinymce-a11y-checker": "^2",
Configurable proficiency ratings page closes OUT-1856, OUT-1858, OUT-2239, OUT-2148 This adds configurable proficiency ratings on the account rubrics page. Persisting these changes will occur in a future patchset (2252). Validating order will be in a separate patchset (2240). test plan: - with the "non-scoring rubrics" feature flag off, the account rubrics page should appear without the proficiency ratings tab - with the "non-scoring rubrics" feature flag on, the accounts rubrics page should appear with the proficiency tab, if visiting with an account with "manage_outcomes" permission (e.g. account admin) - create an account role that has "Create and edit assessing rubrics" permission enabled but "Manage learning outcomes" disabled by going to the account page, click on the "Permissions" link in the left menu, then select the "Account Roles" tab to then be able create the role and enable the permission above. - create an account user by going to the account page and then click on the "People" link in the left menu to then be able to click on "+ New User". you'll use the email address entered in the next step. - make that user an account admin by going to the account page, click on the "Settings" link in the left menu, then select the "Admins" tab, then click on "+ Account Admins". select the new role from the drop down menu and enter the email address you used in the preivous step - confirm with the feature flag enabled, that visiting the account rubrics page does not appear with the proficiency tab, if visiting with an account without "manage_outcomes" permission (e.g. masquerade as the user created above) - on the proficiency tab, test error handling: * description is required * points is required, should be a valid number * when saving changes, all fields with errors should be labelled with an error text, with the first field receiving focus Change-Id: Ic52ef9fe9c58cfb215216b3a505ef1fb4b851c68 Reviewed-on: https://gerrit.instructure.com/150841 Reviewed-by: Michael Brewer-Davis <mbd@instructure.com> Reviewed-by: Frank Murphy <fmurphy@instructure.com> Tested-by: Jenkins QA-Review: Dariusz Dzien <ddzien@instructure.com> Product-Review: Sidharth Oberoi <soberoi@instructure.com>
2018-04-10 09:20:00 +08:00
"uuid": "^3.2.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": {
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"@babel/cli": "^7.0.0",
"@babel/core": "^7.0.0",
add @babel/plugin-transform-react-inline-elements closes: CORE-2749 Now that we use babel-transform-runtime, we can also do this to improve performance over the existing React.createElement calls by inlining the result of what it would have returned. see https://github.com/facebook/react/issues/3228 for why this improves runtime perf so for an example, say you have: const foo = <div className="bar" style={{color: 'red'}}>The Text</div> normally babel would transform that to: var foo = React.createElement("div", { className: "bar", style: { color: 'red' } }, "The Text"); but this will transform it to: var foo = _jsx("div", { className: "bar", style: { color: 'red' } }, void 0, "The Text"); That React.createElement is a lot more complex and slower at runtime, This should make things faster at runtime TEST PLAN: * bundle sizes should stay the same but js runtime for react “render”ing Should be faster in production mode Change-Id: I075d249b9effd0af1b16b9e35c1ddd27696c6955 Reviewed-on: https://gerrit.instructure.com/188865 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-04-10 00:46:49 +08:00
"@babel/plugin-transform-react-inline-elements": "^7.2.0",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"@instructure/ui-babel-preset": "^5",
Add release tracking and source map uploading to sentry This makes it so our sentry instance can be much more detailed in the data that it collects Change-Id: If44ea7bc54646988d681e6ad775951eb0e35436a Reviewed-on: https://gerrit.instructure.com/154010 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-06-16 01:28:53 +08:00
"@sentry/webpack-plugin": "^1.5.2",
A2: implement delete button closes ADMIN-2233 test plan: - click the delete button which will open a confirmation dialog that roughly matches the design - a11y for the dialog should make sense - the close button should dismiss the dialog with no effect - the cancel button should dismiss the dialog with no effect - the delete button should start a delete operation - when the delete operation completes, you should be redirected to the assignment index screen with a message indicating the assignment has been deleted - if your user does not have permission to delete the assignment, or some other error occurs, then the in-development error screen should be shown Change-Id: I0c3304360d3c389296bd0910d02d8215bdb0ac9e Reviewed-on: https://gerrit.instructure.com/177754 Reviewed-by: Carl Kibler <ckibler@instructure.com> Tested-by: Jenkins QA-Review: Carl Kibler <ckibler@instructure.com> Product-Review: Jon Willesen <jonw+gerrit@instructure.com>
2019-01-15 01:33:05 +08:00
"@sheerun/mutationobserver-shim": "0.3.2",
A script to just update instUI Closes: CORE-1709 This is what our Jenkins job to pull in every instui RC commit will use Test plan: * run `yarn upgrade-instructure-ui` * it should make a commit that has new entries in yarn.lock for all the instUI packages that uses the latest rc version on the npm registry * it should not affect anything else besides yarn.lock Change-Id: I78cce6e801015819c4e4b27e26ede352deceebb9 Reviewed-on: https://gerrit.instructure.com/160435 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-08-11 00:22:49 +08:00
"@yarnpkg/lockfile": "^1.0.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
"axe-core": "~2.1.7",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"babel-eslint": "^10",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"babel-jest": "^24",
"babel-loader": "^8",
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",
dynamic import comments refs COMMS-1844 Test Plan: - Click on comments on an A2 student view - notice there is a loading indicator then the comments load Change-Id: I43ed778b826153b5cb4e58b9365a0016dec10897 Reviewed-on: https://gerrit.instructure.com/180618 Tested-by: Jenkins Reviewed-by: Aaron Hsu <ahsu@instructure.com> QA-Review: Landon Gilbert-Bland <lbland@instructure.com> Product-Review: Steven Burnett <sburnett@instructure.com>
2019-02-06 04:54:30 +08:00
"babel-plugin-dynamic-import-node": "^2.2.0",
support testing coffeescript with jest Change-Id: I540ad44c033e489ff49c251256263d547ca258cd Reviewed-on: https://gerrit.instructure.com/182600 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-02-23 14:41:33 +08:00
"babel-plugin-transform-amd-to-commonjs": "^1.4.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
"babel-plugin-transform-react-remove-prop-types": "^0.4",
"coffee-loader": "~0.7.2",
"coffee-script": "^1",
Yarn.lock: update all our npm dependencies closes: CORE-1909 This is the result of running: `yarn upgrade-and-dedupe` and then fixing any specs/changes that needed to happen as a result of the new versions Test plan: * automated tests should pass Change-Id: I79ec63d8eb9d7bce4d48af0cff7cee369be58884 Reviewed-on: https://gerrit.instructure.com/164790 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-09-18 07:08:57 +08:00
"concurrently": "^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
"core-js-builder": "^2",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"css-loader": "^1",
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",
upgrade enzyme to 3.x Closes: CORE-1758 After this commit, if you or your team have any specs that import from old-enzyme-2.x-you-need-to-upgrade-this-spec-to-enzyme-3.x-by-importing-just-enzyme That means you need to upgrade those spec files to use the new enzyme by changing that to `import {mount, shallow, whatever} from ‘enzyme’`. Refer to http://airbnb.io/enzyme/docs/guides/migration-from-2-to-3.html for details Test plan: * all linters-and-js-specs should pass * since this only effects js specs, that is all that really matters. no app code to QA Change-Id: I46c5d815e9d95683832d70b64e31526b943d07e5 Reviewed-on: https://gerrit.instructure.com/135136 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-12-09 01:29:42 +08:00
"enzyme": "^3",
upgrade react from 15.x to 16.x closes: CORE-1874 test plan: Now that the automated selenium & javascript specs pass for this the last thing we need to do is to go manually click around and see if anything breaks. The best thing to do would be to open your browser console and look for errors. Deprecation warnings or propType errors or react warnings are fine but if any actual errors get thrown that is something we want to look into. specific things to look at: * all the gradezilla/gradebook/grading stuff (specifically things that have instUI <NumberInput>s and <Select>s) * look at the submission cell editor * the gb headers (especially make sure keyboard navigation works how it should) * moderated grading * grading perid edit page / enrollment terms * speedgrader * grading standards * gradebook history * theme editor * new discussions/announcements * the new permissions page * the dasboard * student planner * dashcards * global nav trays * help menu * assignment edit page * account user/course search Change-Id: I6a1fe7df9379d9c601eda932bd8cef9c06d10cd2 Reviewed-on: https://gerrit.instructure.com/163913 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-09-11 12:13:01 +08:00
"enzyme-adapter-react-16": "^1",
add enzyme snapshot serializer to jest converts all the existing `expect(component.debug()).toMatchSnapshot()` to: `expect(component).toMatchSnapshot()` which creates more detailed and more diff-able snapshots test plan: - specs pass -- this only affects js test code Change-Id: Ib6dbcc1e3f87e61a251e4635dc68353aca57aeac Reviewed-on: https://gerrit.instructure.com/167651 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-10 03:36:49 +08:00
"enzyme-to-json": "^3.3.4",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"es-check": "^5",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"eslint": "^5",
"eslint-config-airbnb": "^17",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"eslint-config-prettier": "^4",
ESLint standardization This commit introduces a better more reasonable ESLint configuration. It removes all concerns with styling in favor of using prettier to handle those things. closes CORE-2096 Test Plan: - ESLint works Change-Id: I50b90b7191b576bce4817d885d14f18c4c72d208 Reviewed-on: https://gerrit.instructure.com/170874 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-11-03 01:48:59 +08:00
"eslint-plugin-eslint-comments": "^3.0.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
"eslint-plugin-import": "^2",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"eslint-plugin-jest": "^22",
[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-plugin-jsx-a11y": "^6",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"eslint-plugin-lodash": "^5",
[yarn.lock] update :allthethings closes: CORE-1621 This is just the regular commit to update all the npm dependencies. It is the result of running `yarn upgraded-and-dedupe` Test plan: * automated tests should pass * in the review of this, look closely at yarn.lock and see if there is anything that you think might cause problems (eg: a duplicated lib or something else funky like that) Change-Id: I6fdd04f5aa7294464015293fbb3bc0d4a61eeb73 Reviewed-on: https://gerrit.instructure.com/155302 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-07-06 03:18:17 +08:00
"eslint-plugin-notice": "^0.7",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"eslint-plugin-prettier": "^3",
"eslint-plugin-promise": "^4",
"eslint-plugin-qunit": "^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
"eslint-plugin-react": "^7",
"exports-loader": "^0.7",
"expose-loader": "^0.7",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"fetch-mock": "^7",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"file-loader": "^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
"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",
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",
Add a way to generate better js coverage This should pick up coverage from both karma and jest in Canvas proper. It should also pick up coverage from anything under packages/* closes CORE-1265 Test Plan: - Run `COVERAGE=true yarn test` - Coverage reports (coverage-final.json) should generate in all packages such as (canvas-planner) as well as in coverage-karma and coverage-jest - Run `yarn run test:coverage` - coverage-js folder should be generated. Opening index.html should show the full coverage report - Remove coverage-{js, karma, jest} and packages/canvas-planner/coverage as well as .nyc_output to get back to a clean state - Run `RUN_TESTS_FIRST=true yarn run test:coverage` - All tests should run and generate the appropriate report just like the last time in coverage-js Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066 Reviewed-on: https://gerrit.instructure.com/146098 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-04-06 05:27:42 +08:00
"istanbul-merge": "^1.1.1",
Upgrade to babel 7 & allow any js file to be themeable closes: CORE-2699 CORE-2700 UIDEV-99 This commit gets canvas-lms itself upgraded to babel 7. To do that we also had to upgrade jest to v24. We had already got canvas-rce and canvas-planner on jest24/babel7 but now this gets everything to babel 7. so you will see a lot of things removed from yarn.lock since we don’t don’t have to have different versions of everything for babel and jest The other major thing this does is make it so any JS file in canvas can become an @instructure/ui-themeable themeable component. This means you no longer should have to put your css in app/stylesheets for any new react components that you are writing. Test plan: 1. Make sure that the perf of `yarn build:js` is on-par with what it was before. We pass everything through the themeable babel transform now so there is a chance it is slower. If it is majorly slower, we’ll have to figure something out. 2. run a production weback build. The common (or any bundle for that matter should get output exactly the same as it did before) things to manually qa check: * in a NODE_ENV=production enviornment, go to /accounts/site_admin/developer_keys * click the "+ Developer Key" button, it should open the modal. (there are selenium tests that do this, but it was one thing that had to be fixed to get jenkins to pass) * on a course that is set up as a master course, click on the thing that opens the blueprint courses tray. * verify that when you click "Associations" and "Sync History" links in that tray, that they dynamically load the webpack chunk for the modal contents for that thing and then the modal is shown (again, there are selenium specs that test that exact thing but it is always good to manually test it too) Change-Id: I802584228962b54480a500f8fe422f45c2dcac4c Reviewed-on: https://gerrit.instructure.com/183965 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 05:20:27 +08:00
"jest": "^24",
add jest-canvas-mock to silence a bunch of warnings without this we get a bunch of warnings from our jest tests like: Error: Not implemented: HTMLCanvasElement.prototype.getContext … test plan: you shouldn’t see those ^ messages in the jest logs Change-Id: Ib257d4a6b40f4b4118f273729080e722afa3432a Reviewed-on: https://gerrit.instructure.com/163515 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-09-07 12:26:55 +08:00
"jest-canvas-mock": "^1",
support testing coffeescript with jest Change-Id: I540ad44c033e489ff49c251256263d547ca258cd Reviewed-on: https://gerrit.instructure.com/182600 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-02-23 14:41:33 +08:00
"jest-config": "^24",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"jest-dom": "^3",
"jest-junit": "^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
"jest-localstorage-mock": "^2",
Extract jest-moxios-utils to its own package closes CORE-2217 Test Plan: - Automated tests pass Change-Id: Icba5c61344e22e8a8e4929b9133c9a2b89a80ef9 Reviewed-on: https://gerrit.instructure.com/174135 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-12-04 23:19:46 +08:00
"jest-moxios-utils": "^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
"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",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"karma": "^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
"karma-chrome-launcher": "^2",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"karma-coverage-istanbul-reporter": "^2",
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",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"karma-webpack": "^3",
Update and remove duplicate version of lint-staged Test Plan: - Automated tests pass Change-Id: I905418abde9ce75b3d7f1b9e878faeaf7e288b9e Reviewed-on: https://gerrit.instructure.com/177176 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2019-01-09 02:41:32 +08:00
"lint-staged": "^8.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
"merge-stream": "^1",
Pass correct locale to Planner Sometimes ENV.LOCALE and ENV.MOMENT_LOCALE are different (zh-Hans v zh-cn or mi v mi-nz). We were passing the former to planner, but moment needs the full locale, including language and region identifiers, and formatMessage copes with the full locale just fine, so we really need to pass in the latter or moment eventually blows up. So mi-nz month names would successfully parse, had to both bump our version of moment and tweak the canvas customized mi-nz locale data. to test, you'll have to run yarn to update moment, then build with RAILS_LOAD_ALL_LOCALES=1 yarn build Note on the changes to timezoneSpec.js: - some of the specs were parsing dates like "Mon, Aug 3", which are being interpreted in the current year, when Aut 3 is not a Monday. Resolved this by using MockDate to pretend today is 2/1/2015 - moment does not always interpret the Chinese characters for evening as implying PM. I'm assuming canvas will never need that particular construct and commented out the failing string. - there's one date-time that's getting the date totally wrong. - Fixed grammatically incorrect instances of '8月 3, 2015' to ''8月 3日, 2015' - fix cases where the year is coming after the month and day, which would never really happen fixes ADMIN-1331 test plan: - have a student in course so planner is enabled. - go to /profile/settings and Edit - change the Language to Reo Māori (Aotearoa) and "Update Settings" - go to the planner dashboard - click on + to create a new todo > expect you can create a todo. If you want, you can repeat with any of the languages listed in the ticket just to prove ^that wasn't a fluke. Change-Id: I9ba069ef61529088ab92271d7857998df6bbc409 Reviewed-on: https://gerrit.instructure.com/161206 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Reviewed-by: Mysti Sadler <mysti@instructure.com> Reviewed-by: Jeremy Stanley <jeremy@instructure.com> QA-Review: Anju Reddy <areddy@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-08-18 03:21:04 +08:00
"mockdate": "^2.0.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
"moxios": "^0.4",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"nyc": "^13",
[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
"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",
Add raven to grab errors from test runs closes CORE-1532 Test Plan: - Run tests with SENTRY_URL environment variable set - It should attempt to send data to sentry - Build works otherwise Change-Id: Ib802851a7b3ac8626033436f60399f134a8425b3 Reviewed-on: https://gerrit.instructure.com/153878 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-06-15 03:55:22 +08:00
"raven-js": "^3.26.2",
upgrade react from 15.x to 16.x closes: CORE-1874 test plan: Now that the automated selenium & javascript specs pass for this the last thing we need to do is to go manually click around and see if anything breaks. The best thing to do would be to open your browser console and look for errors. Deprecation warnings or propType errors or react warnings are fine but if any actual errors get thrown that is something we want to look into. specific things to look at: * all the gradezilla/gradebook/grading stuff (specifically things that have instUI <NumberInput>s and <Select>s) * look at the submission cell editor * the gb headers (especially make sure keyboard navigation works how it should) * moderated grading * grading perid edit page / enrollment terms * speedgrader * grading standards * gradebook history * theme editor * new discussions/announcements * the new permissions page * the dasboard * student planner * dashcards * global nav trays * help menu * assignment edit page * account user/course search Change-Id: I6a1fe7df9379d9c601eda932bd8cef9c06d10cd2 Reviewed-on: https://gerrit.instructure.com/163913 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-09-11 12:13:01 +08:00
"react-test-renderer": "^16",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"react-testing-library": "^6",
Update redux-logger to 3.0.6 test plan: - automated tests pass Change-Id: Iaf8b223e7c60a43f5b4e10561d5d66643a312992 Reviewed-on: https://gerrit.instructure.com/173817 Tested-by: Jenkins Product-Review: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com>
2018-11-30 09:03:38 +08:00
"redux-logger": "^3.0.6",
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",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"style-loader": "^0.23",
[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
"stylelint": "^9",
"through2": "^2",
revert uglifyjs webpack upgrade Change-Id: I3186254e5916fb335e9b6854f4adfe53f222abad Reviewed-on: https://gerrit.instructure.com/167985 Reviewed-by: Augusto Callejas <acallejas@instructure.com> QA-Review: Augusto Callejas <acallejas@instructure.com> QA-Review: Derek Bender <djbender@instructure.com> Tested-by: Jenkins Product-Review: Derek Bender <djbender@instructure.com>
2018-10-12 07:00:55 +08:00
"uglifyjs-webpack-plugin": "^1.2",
spec: add fetch polyfill for jsdom Because JSDOM has … needs. Change-Id: I3b929d96dc208c6b32802bbfa806cc22adff7fdf Reviewed-on: https://gerrit.instructure.com/177129 Tested-by: Jenkins QA-Review: Jeremy Neander <jneander@instructure.com> Product-Review: Jeremy Neander <jneander@instructure.com> Reviewed-by: Keith Garner <kgarner@instructure.com>
2019-01-08 22:48:21 +08:00
"unfetch": "^4.0.1",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"waait": "^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
"webpack": "^3",
"webpack-cleanup-plugin": "^0.5",
the regular “update all the npm things” commit this updates all the stuff we get from npm that we _can_ upgrade to the newest versions available. test plan: * all the builds should pass Change-Id: Icf1cc3cd02d66e6e1f999ea5f5fc3b5b28775881 Reviewed-on: https://gerrit.instructure.com/167282 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2018-10-04 07:01:30 +08:00
"webpack-manifest-plugin": "^2",
Bump wsrun to the latest version Test Plan: - All workspaces run their tests on jenkins Change-Id: I66fa941a11cdd6306a27b5a374af88755d593472 Reviewed-on: https://gerrit.instructure.com/188718 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-04-09 02:36:08 +08:00
"wsrun": "^3.6.4",
Fix up xsslint to work This also moves us temporarily to a git branch version of xsslint until the official package gets a new release with the appropriate fixes in place. closes CORE-2125 Test Plan: - Automated tests pass - xsslint output shows that it linted many files Change-Id: Id87e872dd2b7a08f11c0ddfaebdfc3f44e86c724 Reviewed-on: https://gerrit.instructure.com/171702 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-11-09 05:06:21 +08:00
"xsslint": "https://github.com/claydiffrient/xsslint.git#master",
[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
},
make inspect-process an optional dependency Change-Id: If62f0601df401e2407a0a606a75c230d1225b205 Reviewed-on: https://gerrit.instructure.com/183822 Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Simon Williams <simon@instructure.com> Tested-by: Jenkins Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-03-05 23:51:37 +08:00
"optionalDependencies": {
"inspect-process": "^0.5"
},
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": {
fix jest tests timing out in jenkins Change-Id: I594d05c5375b20d9eff78487c1a84023ad65e438 Reviewed-on: https://gerrit.instructure.com/184792 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-12 01:06:37 +08:00
"test": "concurrently --names \"packages,jest,karma\" \"yarn test:packages\" \"if [ \"$COVERAGE\" ]; then yarn test:jest:coverage --maxWorkers 1; else yarn test:jest --maxWorkers 1; fi\" \"if [ \"$COVERAGE\" ]; then yarn test:karma; else yarn test:karma:concurrently; fi\"",
Add a way to generate better js coverage This should pick up coverage from both karma and jest in Canvas proper. It should also pick up coverage from anything under packages/* closes CORE-1265 Test Plan: - Run `COVERAGE=true yarn test` - Coverage reports (coverage-final.json) should generate in all packages such as (canvas-planner) as well as in coverage-karma and coverage-jest - Run `yarn run test:coverage` - coverage-js folder should be generated. Opening index.html should show the full coverage report - Remove coverage-{js, karma, jest} and packages/canvas-planner/coverage as well as .nyc_output to get back to a clean state - Run `RUN_TESTS_FIRST=true yarn run test:coverage` - All tests should run and generate the appropriate report just like the last time in coverage-js Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066 Reviewed-on: https://gerrit.instructure.com/146098 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-04-06 05:27:42 +08:00
"test:coverage": "script/generate_js_coverage",
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\"",
Add a way to generate better js coverage This should pick up coverage from both karma and jest in Canvas proper. It should also pick up coverage from anything under packages/* closes CORE-1265 Test Plan: - Run `COVERAGE=true yarn test` - Coverage reports (coverage-final.json) should generate in all packages such as (canvas-planner) as well as in coverage-karma and coverage-jest - Run `yarn run test:coverage` - coverage-js folder should be generated. Opening index.html should show the full coverage report - Remove coverage-{js, karma, jest} and packages/canvas-planner/coverage as well as .nyc_output to get back to a clean state - Run `RUN_TESTS_FIRST=true yarn run test:coverage` - All tests should run and generate the appropriate report just like the last time in coverage-js Change-Id: I50744b8977e0683e079af5bdd2865dbcd6ad9066 Reviewed-on: https://gerrit.instructure.com/146098 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-04-06 05:27:42 +08:00
"test:jest": "jest --color",
spec: [ci-coverage] increase limits for jest coverage Change-Id: I52bfa14af7caa1c71449546c50b07d13d036b47a Reviewed-on: https://gerrit.instructure.com/187716 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Neander <jneander@instructure.com> Product-Review: Jeremy Neander <jneander@instructure.com>
2019-03-31 02:35:15 +08:00
"test:jest:coverage": "node --max-old-space-size=4096 ./node_modules/.bin/jest --color --coverage",
make test:jest:debug open dev tools automatically Change-Id: Ie98f6055f848a4605b4f3276a403f05d345ae2a7 Reviewed-on: https://gerrit.instructure.com/182603 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Tucker Mcknight <tmcknight@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-02-24 05:35:33 +08:00
"test:jest:debug": "inspect node_modules/.bin/jest --runInBand",
Give more memory to karma when it's running This should make it so our post-merge build starts working again and reporting new coverage information. closes CORE-1435 Test Plan: - Run `COVERAGE=true yarn run test:karma` - It should not fail because of memory issues Change-Id: I6e103352fa25e130d0ba8072a77c9d81ac11bb85 Reviewed-on: https://gerrit.instructure.com/150666 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-05-18 06:02:10 +08:00
"test:karma": "yarn run test:karma:watch --single-run",
Disable happypack for concurrent karma runs If we are splitting up our specs and running different groups across different cores, we don’t need to also use happypack to distribute that work to multiple cores. In fact, if we do, it’ll be slower because of cpu thrashing Change-Id: If000c59d73d46961bffebacab9f7b0291a01bda6 Reviewed-on: https://gerrit.instructure.com/164889 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-09-19 03:44:28 +08:00
"test:karma:concurrently": "DISABLE_HAPPYPACK=1 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\"",
Give more memory to karma when it's running This should make it so our post-merge build starts working again and reporting new coverage information. closes CORE-1435 Test Plan: - Run `COVERAGE=true yarn run test:karma` - It should not fail because of memory issues Change-Id: I6e103352fa25e130d0ba8072a77c9d81ac11bb85 Reviewed-on: https://gerrit.instructure.com/150666 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com>
2018-05-18 06:02:10 +08:00
"test:karma:headless": "yarn run test:karma --browsers ChromeHeadlessNoSandbox",
"test:karma:watch": "node --max-old-space-size=4096 ./node_modules/.bin/karma start",
"test:karma:watch:headless": "yarn run test:karma:watch --browsers ChromeHeadlessNoSandbox",
Bump to Node 10 closes CORE-2329 There were some tests that were expecting a snapshot-like value where it expected `new Date().toLocaleDateString()` to give something Like “2016-7-11” but that was actually wrong. If you do `new Date().toLocaleDateString()` in a browser it will give you something like “7/11/2016”. And this new version of node matches what a real browser would have done, so I just updated the specs so they are looking for the correct format. This change does not actually reflect a change in what a real user would see. Just what jest/jsdom/node formats it as. Test Plan: - check to make sure that the assignments 2 availability dates component produces markup exactly as it did before - Automated tests pass - Build canvas locally, everything passes. - Build canvas with docker, everything passes. Change-Id: I74285cd6d9b251ca60ab79396e332cc3a419bcee Reviewed-on: https://gerrit.instructure.com/177198 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-01-09 04:25:49 +08:00
"test:packages": "if [ \"$COVERAGE\" ]; then yarn workspace-run-serial test:coverage; else yarn workspace-run-serial test; fi",
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",
Use yarn workspaces Run `script/nuke_node.sh` to clean everything up Run `yarn install` it should install everything for everything Run `yarn build` and `yarn test` they should work exactly as before Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146 Reviewed-on: https://gerrit.instructure.com/151356 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-05-25 00:09:03 +08:00
"build:packages": "yarn workspace-run build:canvas",
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",
fix pre-commit hook with unfixable eslint error test plan: - have a local yarn install - add an unfixable lint error (unused var) to a file in the prettier whitelist - try to commit the file - it should not try to run in docker after the lint error Change-Id: If1fcfc6693be26c6f6fdddb8cfa4c54a73512ebe Reviewed-on: https://gerrit.instructure.com/173469 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins
2018-11-28 06:40:21 +08:00
"lint:staged": "lint-staged",
Add precommit hook for auto fixing files This only affects javascript files and only affects things from the prettier whitelist This will run slowly if you don't have node_modules installed locally (e.g., in Docker), but it will gladly attempt to run things in Docker for you. This adds a new githook_installer image that will install the githook whenever a docker-compose up happens in the repo. It will also install the hook whenever a `yarn` occurs locally (as a postinstall hook). This commit should also not fail things. For example having unused variables is an ESLint error, but it isn't autofixable. It will log the error, but will otherwise continue. However, it will make this pretty with prettier as well as fix any other autofixable ESLint errors. closes CORE-2118 Test Plan: - Run `yarn` - Add some semicolons to something from the whitelist - git add that file - git commit and it will strip semicolons - In a dockerized Canvas: - docker-compose up - Add semicolons to a file - git add that file - git commit, it will take forever (~60s) - It should have stripped out semicolons Change-Id: Id9198aa008808e898f29acb9ed64dd14ff843222 Reviewed-on: https://gerrit.instructure.com/171510 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-11-08 07:04:08 +08:00
"postinstall": "yarn build:packages && ./script/install_hooks",
turn off webpack progress for less noisy builds This patchset also enables linting of webpack development to ensure es6 compatability. Before this patchset, gulp was invoked with an ampersand to make it a background process. However since it only takes a few seconds to run, it's success messages would be interlaced with webpack's output. This reads rather odd in our logs. Since gulp is a low-churn tool in canvas, let's mute stdout but still display stderr if an error should appear. Change-Id: I48846758e839480c9bc5779bfe64201e90713e2b Reviewed-on: https://gerrit.instructure.com/170833 Tested-by: Jenkins Reviewed-by: Rex Fleischer <rfleischer@instructure.com> QA-Review: Derek Bender <djbender@instructure.com> Product-Review: Derek Bender <djbender@instructure.com>
2018-11-02 23:24:33 +08:00
"webpack": "gulp rev 1> /dev/null & webpack --progress --color --watch",
"webpack-development": "gulp rev 1> /dev/null & webpack --color && yarn lint:browser-code",
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",
Bump wsrun to the latest version Test Plan: - All workspaces run their tests on jenkins Change-Id: I66fa941a11cdd6306a27b5a374af88755d593472 Reviewed-on: https://gerrit.instructure.com/188718 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2019-04-09 02:36:08 +08:00
"workspace-run": "r() { wsrun --fast-exit --exclude-missing --collect-logs --report -c $@; exit $?; } && r",
"workspace-run-serial": "r() { wsrun --fast-exit --exclude-missing --collect-logs --report --serial -c $@; exit $?; } && r",
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",
A script to just update instUI Closes: CORE-1709 This is what our Jenkins job to pull in every instui RC commit will use Test plan: * run `yarn upgrade-instructure-ui` * it should make a commit that has new entries in yarn.lock for all the instUI packages that uses the latest rc version on the npm registry * it should not affect anything else besides yarn.lock Change-Id: I78cce6e801015819c4e4b27e26ede352deceebb9 Reviewed-on: https://gerrit.instructure.com/160435 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-08-11 00:22:49 +08:00
"upgrade-and-dedupe": "rm -rf yarn.lock node_modules && yes 1 | yarn install --flat --production --ignore-scripts && git checkout package.json && yarn install && git add yarn.lock",
"upgrade-instructure-ui": "script/upgrade-instructure-ui"
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",
Use yarn workspaces Run `script/nuke_node.sh` to clean everything up Run `yarn install` it should install everything for everything Run `yarn build` and `yarn test` they should work exactly as before Change-Id: I11a27ff2d705c6cbb3b3f9029dd8b32138706146 Reviewed-on: https://gerrit.instructure.com/151356 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-05-25 00:09:03 +08:00
"canvas-quizzes/grunt-contrib-jasmine/jasmine-core": "2.6.4",
put accidentally deleted comments back in package.json Change-Id: I6b00f817afbf46c6cfa48ed0f389aede78c9c3f3 Reviewed-on: https://gerrit.instructure.com/163733 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-09-09 13:17:24 +08:00
"graphael": "this is just here so yarn.lock looks the same whether the analytics plugin is checked out or not",
Upgrade canvas-planner & rce to not use ui-presets This gets canvas planner and canvas-rce on babel 7, which is a prerequisite to canvas doing the same. Also, by not depending on the Kitchen sink of ui-presets, it cleans a ton of unused stuff from our node_modules/yarn.lock. It was originally 2 different commits but in order to get the yarn.lock right, we have to do them all as one. This also made it so we needed to have less “resolutions” in our package.json since the newer versions of those things work fine with the newer version of babel So there are 2 test plan areas: 1. Canvas-planner Closes: CORE-2575 Test plan: * smoke test to make sure everything in canvas-planner still works/looks like it used to in the canvas ui * make sure the translation task (yarn check-transifex) still works canvas-rce: upgrade to babel 7 & @instructure/ui-babel-preset 2. canvas-rce Closes: CORE-2576 Test plan: * smoke test the RCE editor * theming should still work/look exactly as before * make sure all the various build tasks (eg yarn test, test:coverage, debug, lint, extract, etc) all still work as before Change-Id: Id896687e3905f4df4627b181cad3f67ffe4417a5 Reviewed-on: https://gerrit.instructure.com/183877 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2019-03-06 02:30:44 +08:00
"graphael": "https://github.com/ryankshaw/graphael.git"
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
}
maintain precision of grades in grade input fixes GRADE-1098 test plan: 1. Create an Assignment a. with Display Grade as Percentage b. worth 9.5 points 2. Open New Gradebook 3. Grade a student on this assignment twice a. once with 55 (interpreted as percentage) b. again with 55% (explicit percentage) 4. Verify grade is 55% 5. Verify score is 5.225 Change-Id: Ie48ec7d5b787e864bfd3379e8dc6a4dbebebc2e5 Reviewed-on: https://gerrit.instructure.com/148848 Tested-by: Jenkins Reviewed-by: Derek Bender <djbender@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: Shahbaz Javeed <sjaveed@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com>
2018-05-02 04:54:56 +08:00
}