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

188 lines
7.0 KiB
JSON
Raw Normal View History

AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
{
"name": "canvas-lms",
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"license": "AGPL-3.0",
AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
"version": "0.0.0",
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"engines": {
Use node 8.10.0 instead of 8.9.4 Test plan: * automated builds should pass * docker stuff should work Change-Id: I120e5689b6b219dc295517e92047cdf3f8b5d61e Reviewed-on: https://gerrit.instructure.com/143022 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-09 04:33:46 +08:00
"node": ">=8.10.0",
Update to yarn 1.5.1 closes GH-1250 Test Plan: - Everything builds Change-Id: Id51b8997f5ae1b53c24c2b4b616c6956833ed2b5 Reviewed-on: https://gerrit.instructure.com/142553 Reviewed-by: Jeremy Neander <jneander@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Derek Bender <djbender@instructure.com> Tested-by: Jenkins
2018-03-06 00:12:09 +08:00
"yarn": "1.5.1"
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
},
move napa from "devDependencies" to "dependencies" Change-Id: I4dde9458868cd5c1c41b921414dff4b3dc9371de Reviewed-on: https://gerrit.instructure.com/29878 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Jason Madsen <jmadsen@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-02-11 02:29:11 +08:00
"dependencies": {
Upgrade Canvas to INSTUI 4.7.2 Fixes: UIDEV-170 Updates the parts of Canvas that were using 4.7.1 to the 4.7.2 patch release to add a bugfix for List/ListItem where two badly-scoped CSS selectors were selecting every element on the Canvas dashboard. Test plan: - Confirm ToDo List on Canvas dashboard is working as it should - Confirm the selectors shown in the screenshot in the JIRA ticket are now only targeting first and last items in the List component (see ToDo List in sidebar): https://www.screencast.com/t/cq4W4MGcemn Change-Id: I16c4bad0ef2bac76d0e9a4d34d6ce9869ab0587c Reviewed-on: https://gerrit.instructure.com/141100 Reviewed-by: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins QA-Review: Dan Sasaki <dsasaki@instructure.com> Product-Review: Chris Hart <chart@instructure.com>
2018-02-16 02:57:05 +08:00
"@instructure/ui-core": "^4.7.2",
"@instructure/ui-themeable": "^4.7.2",
"@instructure/ui-themes": "^4.7.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
"axios": "^0.16.0",
"backbone": "1.1.1",
Remove remaining dynamic brand css code closes: CNVS-39103 CNVS-39104 CNVS-38650 test plan: * do a general css styling regression pass * make sure that the urls to css files look like /dist/brandable_css/new_styles_normal_contrast/<bundle>-<fingerprint>.css and not: /dist/brandable_css/<big long md5>/new_styles_normal_contrast/<bundle>-<fingerprint>.css * make sure that stylesheets loaded by handlebars templates work eg: go to the calendar page and make sure it is styled correctly * verify that the theme editor works. especially the process when you hit "preivew" and "apply" * set up config/canvas_cdn.yml to use the dev cdn * run `bundle exec canvas:compile_assets && bundle exec rake canvas:cdn:upload_to_s3` * load a page, all the css should load from the cdn * verify the theme editor works when using the cdn too. * also review the changes in the brandable_css npm package: https://github.com/ryankshaw/brandable_css/compare/c6bef...b159d5 Change-Id: I55db41e90f6bc54183a661128f1050445a086d6b Reviewed-on: https://gerrit.instructure.com/120912 Tested-by: Jenkins Reviewed-by: Cody Cutrer <cody@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2017-09-26 07:19:15 +08:00
"brandable_css": "0.1.0",
don’t cp all of canvas-planner’s node_modules dir this is to prevent canvas from copying everything in canvas-planner’s node_modules dir into /node_modules/canvas-planner/node_modules this will mimic the exact same behavior that pushing it to the npm repository and pulling it from there in canvas’s package.json test plan: * do `ls node_modules/canvas-planner/node_modules/jest*` * you should get: ls: node_modules/canvas-planner/\ node_modules/jest*: No such file or directory Change-Id: Ie428b3d0a5d6cc1d9bec89ae00adb3d451dfc916 Reviewed-on: https://gerrit.instructure.com/139907 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-02-06 04:41:27 +08:00
"canvas-planner": "file:./packages/canvas-planner/copy-of-what-gets-published-to-npm-registry",
upgrade canvas-rce to 3.0.2 upgrades instructure-ui and fixes a microsoft edge but when inserting equations. closes CORE-906 test plan: - smoke test rce sidebar for inst-ui upgrade - open an editor in edge - insert an equation using the equation editor - it should show the equation, not an X with the alt text Change-Id: Ieb44771ddbba911598d75b20367b246e6f83fc20 Reviewed-on: https://gerrit.instructure.com/140895 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-14 13:20:13 +08:00
"canvas-rce": "3.0.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",
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",
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",
"graphql": "^0.10.0",
"ic-ajax": "~2.0.1",
"ic-tabs": "0.1.3",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"immutability-helper": "^2",
"instructure-icons": "^4",
bump canvas to instui 3.3.4 fixes ADMIN-570 refs ADMIN-80, ADMIN-259 test plan: - try test plan from ADMIN-80 - try test plan from ADMIN-259 Change-Id: I0169be49b732ad89a5d6fe44934ddab8b600fec0 Reviewed-on: https://gerrit.instructure.com/133886 Tested-by: Jenkins Reviewed-by: Dan Minkevitch <dan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com> QA-Review: Ed Schiebel <eschiebel@instructure.com>
2017-11-28 05:38:54 +08:00
"instructure-ui": "3.3.4",
Make it so it works with newest yarn (1.3.2) test plan: * while running yarn 0.27, * run `yarn` * it should work and there should only be one jquery in node_modules * brew upgrade yarn (or whatever else you do to upgrade yarn to 1.3.2) * run `yarn` * it should work and not make any changes to yarn.lock or node_modules Change-Id: Idf2eefbc1707d4c77ec8d1d6a78909240fd9b9f9 Reviewed-on: https://gerrit.instructure.com/133500 Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-22 04:03:43 +08:00
"jquery": "https://github.com/ryankshaw/jquery.git#a755a3e9c99d5a70d8ea570836f94ae1ba56046d",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"jquery-getscrollbarwidth": "^1.0.0",
"jquery-ui-touch-punch": "^0.2.3",
"jquery.cookie": "^1.4.1",
Update yarn/npm dependencies this will make it so we can use karma with the latest node. once the commit to upgrade d3 is merged, that was the only other thing we needed to do to have everything working on node 8. Change-Id: I820b27ee3da38818b69554c6e409a2177370ca34 Reviewed-on: https://gerrit.instructure.com/136752 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-01-03 06:24:44 +08:00
"jquery.elastic": "1.0.0",
get window.location.orgin polyfill from npm …instead of the copy-pasta’ed one in our repo Test plan: Make sure the files search results page works in ie11 Change-Id: I61433363eda53d44b897bf1f88837cef7c239f87 Reviewed-on: https://gerrit.instructure.com/135141 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-09 08:32:58 +08:00
"location-origin": "^1.1.4",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"lodash": "^4.16.4",
"md5": "^2.2.1",
Upgrade mediaelement to latest master of our fork Fixes: CORE-1091 show controls when they receive focus (#39) if controls are visibly hidden, they should still be tabbable for accessibility, and when they get keyboard-focused, they should become visible again. See: https://github.com/instructure/mediaelement/commit/0402b2b76 Change-Id: Ic655d43a64d111662f8d7368f21032664a8aee74 Reviewed-on: https://gerrit.instructure.com/142693 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-07 00:03:37 +08:00
"mediaelement": "https://github.com/instructure/mediaelement.git#master",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"moment": "~2.10.6",
"page": "visionmedia/page.js#1.6.4",
update parse-decimal-number to 1.0.0 A hack can be removed for parsing numbers now that 1.0.0 incorporates the needed behavior. test plan: * verify Jenkins passes Change-Id: Ifaea8fd348f4f804e9a6042fb392c699badeea6e Reviewed-on: https://gerrit.instructure.com/138046 Tested-by: Jenkins Reviewed-by: Derek Bender <djbender@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Jeremy Neander <jneander@instructure.com> QA-Review: Jeremy Neander <jneander@instructure.com>
2018-01-17 00:52:42 +08:00
"parse-decimal-number": "1.0.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"prop-types": "^15",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"qs": "https://github.com/hapijs/qs.git#a341cdf2fadba5ede1ce6c95c7051f6f31f37b81",
"react": "0.14.9",
"react-addons-css-transition-group": "0.14.8",
"react-addons-pure-render-mixin": "0.14.8",
use graphql for student context cards closes CNVS-37584 Test plan: - student context cards should work as usual with graphql turned off - when graphql is on, student context cards should behave identically, but should hit the /api/graphql endpoint instead of the REST api Change-Id: I723ac48a7c7f58c4b6065b92ec37c9985498c9d3 Reviewed-on: https://gerrit.instructure.com/122427 Tested-by: Jenkins Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> QA-Review: Collin Parrish <cparrish@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com>
2017-08-11 05:11:44 +08:00
"react-apollo": "^1.4.12",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"react-crop": "^4.0.2",
"react-dnd": "2.1.4",
"react-dnd-html5-backend": "2.1.2",
"react-dom": "0.14.9",
"react-modal": "1.6.5",
"react-redux": "4.4.5",
"react-select-box": "https://github.com/instructure-react/react-select-box.git#b1ddd39223d48793fbe3dc4e87aca00d57197b5f",
"react-tokeninput": "2.4.0",
"redux": "^3.5.2",
"redux-actions": "0.11.0",
"redux-thunk": "2.1.0",
"spin.js": "2.3.2",
"swfobject": "^2.2.1",
"tablesorter": "^2.28.5",
bump timezone.js closes CORE-577 test plan: * smoke test some datetime pickers, and maybe try a language or two Change-Id: I808d64c20e89ed287a38fda5f00d61a8f422bae7 Reviewed-on: https://gerrit.instructure.com/139326 Tested-by: Jenkins Reviewed-by: Rob Orton <rob@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Cody Cutrer <cody@instructure.com>
2018-01-27 05:55:38 +08:00
"timezone": "1.0.13",
move things from “devDeps” to “dependencies” Closes CNVS-39744 we used to only have the things needed to compile brandable_css in “Dependencies”. This was because, when we used to have to run brandable_css on a job server when someone pressed “preview” in the theme editor, we only wanted to have the minimum amount of node_modules installed there to do that. But now that we no longer have to do any brand-specific css compiling we can just do what is considered normal and put anything that actually goes on the page in “dependencies” and leave all the build tooling, linting, etc stuff in devDependencies. This also makes it so it is really easy to see the cases that we might be loading 2 versions of something in our webpack bundles by running `yarn install --prod --flat`. Whatever that prompts you about is something that will be included more than once in our webpack bundles. Test plan: * run `yarn install` * it should not generate a new yarn.lock because everything is the same versions as before. Change-Id: I87b88f50d2cdbe494f928e5418e8540da9cc084c Reviewed-on: https://gerrit.instructure.com/128244 Tested-by: Jenkins Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-10-04 01:05:04 +08:00
"tinycolor2": "1.4.1",
"tinymce": "4.5.7",
upgrade a11y checker to 1.3.3 fixes untranspiled es6 that was breaking the prod build closes CORE-972 Change-Id: Ic1068ed2eda81f0167563fb37c8d57473da30338 Reviewed-on: https://gerrit.instructure.com/139858 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-06 01:11:48 +08:00
"tinymce-a11y-checker": "1.3.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
"tinymce-light-skin": "1.3.1"
move napa from "devDependencies" to "dependencies" Change-Id: I4dde9458868cd5c1c41b921414dff4b3dc9371de Reviewed-on: https://gerrit.instructure.com/29878 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Jason Madsen <jmadsen@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-02-11 02:29:11 +08:00
},
AMD Conversion "Trivial" JavaScript / CoffeeScript changes -------------------------------------------------- For the most part, all javascript was simply wrapped in `require` or `define`. The dependencies were found with a script that matched regexes in the files, it errs on the side of listing too many dependencies, so its worth double checking each file's dependencies (over time, anyway). i18n API changes -------------------------------------------------- No longer have to do I18n.scoped calls, just list i18n as a dependency with the scope and it's imported already scoped require ['i18n!some_scope'], (I18n) -> I18n.t 'im_scoped', 'I'm scoped!' JS bundling now done with r.js, not Jammit -------------------------------------------------- We don't use jammit to bundle JS anymore. Simply list dependencies for your JS modules in the file and RequireJS handles the rest. To optimize the JavaScript, first make sure you have node.js 0.4.12+ installed and then run: $ rake js:build The app defaults to the optimized build in production. You can use non-optimized in production by putting ?debug_assets=true in the url just like before. You can also test the optimized JavaScript in development with ?optimized_js=true. Significant changes -------------------------------------------------- These files have "real" changes to them (unlike the JavaScript that is simply wrapped in require and define). Worth taking a really close look at: - app/helpers/application_helper.rb - app/views/layouts/application.html.erb - config/assets.yml - config/build.js - lib/handlebars/handlebars.rb - lib/i18n_extraction/js_extractor.rb - lib/tasks/canvas.rake - lib/tasks/i18n.rake - lib/tasks/js.rake Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7 Reviewed-on: https://gerrit.instructure.com/6986 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Ryan Florence <ryanf@instructure.com>
2011-11-11 00:31:45 +08:00
"devDependencies": {
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"axe-core": "~2.1.7",
"babel-cli": "^6",
"babel-core": "^6",
"babel-eslint": "^8",
"babel-jest": "^22",
"babel-loader": "^7",
Bump Babel to version 6 closes CNVS-29019 closes gh-817 Test Plan: - bundle exec rake canvas:compile_assets should compile /app/jsx and /specs/javascripts/jsx properly - Automated tests should pass - Areas of Canvas that use JSX/ES6 should work properly such as Moderated Grading, Files, and the new Admin search page Change-Id: Ic2aefbe98dd65a9b38407a68dc569e19a9e300e2 Reviewed-on: https://gerrit.instructure.com/78232 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> QA-Review: Heath Hales <hhales@instructure.com> Product-Review: Clay Diffrient <cdiffrient@instructure.com>
2016-07-09 00:16:46 +08:00
"babel-plugin-add-module-exports": "0.2.1",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"babel-plugin-transform-react-remove-prop-types": "^0.4",
"babel-plugin-transform-runtime": "^6",
"babel-polyfill": "^6",
"babel-preset-env": "^1",
"babel-preset-react": "^6",
"babel-preset-stage-1": "^6",
"babel-register": "^6",
"coffee-loader": "~0.7.2",
"coffee-script": "^1",
"concurrently": "^3",
"core-js-builder": "^2",
"css-loader": "^0.28",
use web pack closes CNVS-24124 makes working with web pack possible in canvas instead of require-js. See doc/working_with_webpack.md for instructions. TEST PLAN: Nothing should change in non-webpack'd behavior Things should mostly work when you use the USE_WEBPACK environment variable, but make sure to document and ticket things that don't Change-Id: I493a259a609e9e183950bc57aa5876df70108547 Reviewed-on: https://gerrit.instructure.com/64386 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ethan Vizitei <evizitei@instructure.com> QA-Review: Ethan Vizitei <evizitei@instructure.com>
2015-10-01 11:16:11 +08:00
"ember-template-compiler": "^1.8.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"enzyme": "^2",
"eslint": "^4",
Update a bunch of npm dependencies Change-Id: I089fa97c1e18417f52e7b3baa9ba618129820755 Reviewed-on: https://gerrit.instructure.com/133722 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-23 03:07:54 +08:00
"eslint-config-airbnb": "^16.1.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"eslint-config-prettier": "^2",
"eslint-plugin-import": "^2",
"eslint-plugin-jest": "^21",
"eslint-plugin-jsx-a11y": "^6",
"eslint-plugin-notice": "^0.6",
"eslint-plugin-promise": "^3",
"eslint-plugin-qunit": "^3",
"eslint-plugin-react": "^7",
"exports-loader": "^0.7",
"expose-loader": "^0.7",
git rid of our vendor’ed fork of mediaelement refs: CORE-24 test plan: * this net result of this change should mean that we are using the exact same code as we were using before, just pulled from github directly in our package.json instead of vendored into our repo. * testing the follow-on commits should show this worked correctly Change-Id: Ie6d022d5fe8ed1a607f66f9d426c47ec7e8f5b14 Reviewed-on: https://gerrit.instructure.com/142381 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-02 06:35:05 +08:00
"file-loader": "^1.1.10",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"fontfaceobserver": "^2",
update gglobby npm dep refs: CNVS-29725 test plan: * run `node script/xsslint.js` * it should work (this is ran by jenkins so reall if it passes, it is good) Change-Id: Ib9b68e486c32c91e3c430cea095a628daf51db2b Reviewed-on: https://gerrit.instructure.com/87181 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2016-08-09 07:39:19 +08:00
"gglobby": "0.0.3",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"glob": "^7",
"gulp": "^3",
"gulp-file": "^0.4",
"gulp-filter": "^5",
"gulp-insert": "^0.5",
"gulp-load-plugins": "^1",
"gulp-rename": "^1",
"gulp-rev": "^8",
"gulp-sourcemaps": "^2",
"gulp-uglify": "^3",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"handlebars": "1.3.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"handlebars-loader": "^1",
upgrade webpack related npm modules Refs: CNVS-38653 This upgrades us to webpack 3.5.4 and upgrades uglify and Istanbul related stuff too: Test plan: * automated build should pass * run yarn && COVERAGE=1 yarn test && open coverage-js/index.html * it should run karma & open your browser to a bunch of istambul reports * run `yarn run webpack-production` * it should generate minified code that works in your browser when you open canvas in prod mode Change-Id: Id8b3c2457f47a30f299eafc6a8206102cfe98dc5 Reviewed-on: https://gerrit.instructure.com/122993 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-08-15 07:07:13 +08:00
"happypack": "^3.1.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"imports-loader": "^0.8",
"istanbul-instrumenter-loader": "^3",
"jest": "^22",
"jest-junit": "^3",
"jest-localstorage-mock": "^2",
"json-loader": "^0.5.7",
web pack port of quiz statistics refs CNVS-25916 remove dynamic requirements for env configs, use separate jsx loader for client apps, update client app plugin to use old react version, rewrite selenium spec to be an integration test rather than executing arbitrary javascript, and MAJORLY refactor loading patterns of client apps to avoid sharing code with differences delineated by opaque require re-writes. Also moved some code that was in "common" client app but only used by one actual client app down into the app that uses it (simplifies dependency tracing). TEST PLAN: 1) make sure quiz statistics still works ok under require js build, no behavior should have changed 2) also make sure quiz log auding works under require-js Change-Id: I0e5ee3eda9da16e0ad48cf858761735c71df801c Reviewed-on: https://gerrit.instructure.com/69804 Tested-by: Jenkins Reviewed-by: Ryan Taylor <rtaylor@instructure.com> QA-Review: Michael Hargiss <mhargiss@instructure.com> Product-Review: Ethan Vizitei <evizitei@instructure.com>
2016-01-07 06:31:33 +08:00
"jsx-loader": "0.11.2",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma": "^2",
"karma-chrome-launcher": "^2",
"karma-coverage-istanbul-reporter": "^1",
Make changes for node 12/iojs. This makes a number of changes to get the compilation compatible with node 12 and iojs. - removes loom (no longer used) - updates karma dependencies to more recent versions - minor css change to make sass compilation work with node-sass (lib-sass) test plan: - should be able to compile assets with node 12 and iojs - JS specs still pass Change-Id: Id4a0628ff0c6dd09e622d02329a4400d60459ec2 Reviewed-on: https://gerrit.instructure.com/49493 Tested-by: Jenkins Reviewed-by: Nick Houle <nhoule@instructure.com> Product-Review: Cameron Matheson <cameron@instructure.com> QA-Review: Cameron Matheson <cameron@instructure.com>
2015-02-26 06:28:11 +08:00
"karma-firework-reporter": "~0.2.4",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-junit-reporter": "^1",
Update yarn.lock with newest versions of deps closes: CNVS-38384 This is just to keep our tooling up to date Test plan: * automated tests should pass * build tooling should work (meaning webpack builds In prod & dev) Change-Id: I11fbda35827487e59712c762a71540a51258d1db Reviewed-on: https://gerrit.instructure.com/120434 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 01:29:52 +08:00
"karma-qunit": "~1.2.1",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-sourcemap-loader": "^0.3",
publish jUnit test result file from karma tests Test plan: * run `yarn test` * there should be xml file in coverage-js/karma-test-results.xml With the spec results that we will use for Jenkins builds Change-Id: Ic68de197d2b52dbccdf58dc2d148aef1f2ca2646 Reviewed-on: https://gerrit.instructure.com/135949 Tested-by: Jenkins Reviewed-by: Robert Lamb <rlamb@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 23:21:42 +08:00
"karma-spec-reporter": "^0.0.32",
Update yarn.lock with newest versions of deps closes: CNVS-38384 This is just to keep our tooling up to date Test plan: * automated tests should pass * build tooling should work (meaning webpack builds In prod & dev) Change-Id: I11fbda35827487e59712c762a71540a51258d1db Reviewed-on: https://gerrit.instructure.com/120434 Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-07-26 01:29:52 +08:00
"karma-verbose-reporter": "^0.0.6",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"karma-webpack": "2.0.6",
"merge-stream": "^1",
"moxios": "^0.4",
"prettier": "^1",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"qunitjs": "^1.14.0",
use node_modules wherever possible closes: CNVS-31787 the only things left in bower are things that are just not avalable on npm because they are so old. we'll have to continue using the bower versions of them, but it's ok since they are mostly old ember stuff that will be ripped out when we finish our react screenreader gradebook also: remove some ember stuff that wasn't being used anymore. nothing was using this stuff test plan: this really does touch a lot of stuff. some things to check out specifically in the prod/optimized requireJS build: (load the page, click around to make sure things work) the screenreader gradebook client_apps: quiz statistics quiz event logging creating a new student group calendar, try all the views (month/agenda/etc) gradebook 2 turn on the new course/user search feature for your account and go to accounts/x and search for a user/course the new react gradebook use tinymce on a page, make sure that both the service and local version of it work Change-Id: I4322a154d289760ab51b92e34dd7fac808b41ba8 Reviewed-on: https://gerrit.instructure.com/93102 Tested-by: Jenkins QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com> Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2016-10-19 01:11:26 +08:00
"react-addons-test-utils": "0.14.8",
move redux-logger from prod deps to devDeps Because nothing should be including or using redux-logger in production, It is safe to move it to devDependencies Test plan: * automated builds should pass Change-Id: Ic532f86a559a748388dc2d6b0481f760debc2ac0 Reviewed-on: https://gerrit.instructure.com/133702 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-23 02:57:48 +08:00
"redux-logger": "2.6.1",
Upgrade instructure-ui to 1.0 fixes CNVS-34969 test plan: - go /profile/settings and turn on high contrast - go to the course people page (/courses/#/users) - click on the +People button > expected result: the modal honors high contrast - enter some text in he text area > expected result: nothing bad happens, as the event handler for TextArea has changed. - there's a TextArea in MessageStudents also, but I don't know where to find it in the UI. You should probalby test it doesn't blow up either. Change-Id: Ia8102dacfa2b01ee043002ee0f5c27943abe5743 Reviewed-on: https://gerrit.instructure.com/102133 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Dan Sasaki Product-Review: Ryan Shaw <ryan@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2017-02-15 05:54:51 +08:00
"requirejs": "~2.2.0",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"script-loader": "^0.7",
"sinon": "^4",
"style-loader": "^0.20",
"stylelint": "^9",
"through2": "^2",
"webpack": "^3",
"webpack-cleanup-plugin": "^0.5",
"webpack-manifest-plugin": "^1",
"webpack-parallel-uglify-plugin": "^1",
make all locale files agree on short month names fixes CNVS-34165 test plan: - make sure you are running with RAILS_LOAD_ALL_LOCALES=1 for (web and webpack if you are running docker) - change locale to each of es, de, fr, fr-ca, he and pl - create/edit a quiz - in the due date try setting the due date to a day in each month - no need to save - make sure after clicking the day it doesn't change to a different month or year Change-Id: I2da96f80678193e084786d867b27f2944a6e402c Reviewed-on: https://gerrit.instructure.com/119926 Tested-by: Jenkins Product-Review: brian kirkby <bkirkby@instructure.com> Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> Reviewed-by: brian kirkby <bkirkby@instructure.com> QA-Review: Tucker McKnight <tmcknight@instructure.com>
2017-07-20 23:50:43 +08:00
"xsslint": "0.1.4",
[npm dependencies] update all our npm dependencies This is just the regular “update all the things” commit. For things in package.json that we just want the latest version of, I changed them to a simple major with a carat. (Eg: “8^” or “4^”), that way you can see easier which things are specifically locked down To a specific version (or range of versions) for a reason. Test plan: * automated specs & build tasks should work Change-Id: Id7a3f853bd0f7537cc0f08d7dba8d6726b836c44 Reviewed-on: https://gerrit.instructure.com/141653 Tested-by: Jenkins Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com> QA-Review: Brent Burgoyne <bburgoyne@instructure.com> Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
2018-02-23 03:58:38 +08:00
"yaml-loader": "^0.5"
clean up JS tests and integrate karma - js:generate_runner now generates common files to be used by different test runners - js spec file order now shuffled to better expose dependencies - fakeENV now returns two methods: setup and teardown - stock tinymce 3 files are now wrapped for AMD test plan: - tinymce should work the same - js:test rake task should run tests - js:build task should work as normal (using new location of r.js) - test results should successfully send to firework Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2 Reviewed-on: https://gerrit.instructure.com/29297 QA-Review: Shawn Meredith <shawn@instructure.com> Tested-by: Shawn Meredith <shawn@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-01-24 23:58:37 +08:00
},
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"jest-junit": {
"output": "./coverage-js/junit-reports/jest.xml"
},
upgrade karma everyone was getting build errors when they were npm install'ing. it was because karma 0.10 depended on an out-of-date version of chokiadr that does not compile against node 0.12 I also indicated that canvas is licenced agpl 3 so that you wouldn't always see an npm warning about not having one. also, let karma serve our css files so if any javascript references them in our quit tests, we don't see 404 warnings Change-Id: Iaa0377bc87b8f7ec8726d6cb82c0f8a103134b56 Reviewed-on: https://gerrit.instructure.com/58584 Tested-by: Jenkins Reviewed-by: Mike Nomitch <mnomitch@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2015-07-16 12:24:49 +08:00
"repository": "instructure/canvas-lms",
clean up JS tests and integrate karma - js:generate_runner now generates common files to be used by different test runners - js spec file order now shuffled to better expose dependencies - fakeENV now returns two methods: setup and teardown - stock tinymce 3 files are now wrapped for AMD test plan: - tinymce should work the same - js:test rake task should run tests - js:build task should work as normal (using new location of r.js) - test results should successfully send to firework Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2 Reviewed-on: https://gerrit.instructure.com/29297 QA-Review: Shawn Meredith <shawn@instructure.com> Tested-by: Shawn Meredith <shawn@instructure.com> Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com> Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com> QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
2014-01-24 23:58:37 +08:00
"scripts": {
Move planner under canvas-lms closes: CORE-949 this also upgrades us to use what was on canvas-planner master as of 1pm on 2/1/2018 (specifically 9569cc1) test plan: * canvas planner should work * all automated builds should pass Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2 Reviewed-on: https://gerrit.instructure.com/135947 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 22:39:39 +08:00
"test": "concurrently --names \"packages,jest,karma\" \"yarn test:packages\" \"jest\" \"if [ \"$COVERAGE\" ]; then yarn test:karma; else yarn test:karma:concurrently; fi\"",
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"test:watch": "concurrently --names \"jest,karma\" \"jest --watch .\" \"yarn test:karma:watch\"",
"test:jest": "echo 'this is here just so you know you can use jest, but just use the `jest` cli directly' && jest",
"test:karma": "karma start --single-run",
"test:karma:concurrently": "concurrently --names \"coffee,js1,js2\" \"JSPEC_GROUP=coffee yarn test:karma:headless\" \"JSPEC_GROUP=js1 yarn test:karma:headless\" \"JSPEC_GROUP=js2 yarn test:karma:headless\"",
"test:karma:headless": "karma start --single-run --browsers ChromeHeadlessNoSandbox",
"test:karma:watch": "karma start",
"test:karma:watch:headless": "karma start --browsers ChromeHeadlessNoSandbox",
Put finishing touches on planner under canvas - update README with new instructions - update how canvas runs sub-package tests - remove planner's test server closes ADMIN-742 test plan: - when jenkins runs, check to see that planner's tests run too Change-Id: I2493b65f580c76b28f225f1330e99e1ceb1378b4 Reviewed-on: https://gerrit.instructure.com/139882 Tested-by: Jenkins Reviewed-by: Jon Willesen <jonw+gerrit@instructure.com> QA-Review: Jon Willesen <jonw+gerrit@instructure.com> Product-Review: Ed Schiebel <eschiebel@instructure.com>
2018-02-06 02:59:45 +08:00
"test:packages": "script/local-yarn test",
Move planner under canvas-lms closes: CORE-949 this also upgrades us to use what was on canvas-planner master as of 1pm on 2/1/2018 (specifically 9569cc1) test plan: * canvas planner should work * all automated builds should pass Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2 Reviewed-on: https://gerrit.instructure.com/135947 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 22:39:39 +08:00
"preinstall": "script/local-yarn install",
make npm build scripts more user friendly :) test plan: - run the following commands and assess that they run as expected: - yarn run build - yarn run build:css - yarn run build:css:watch - yarn run build:js - yarn run build:jss:watch Change-Id: I4c0a2a68ce62896364bc2da5e7956002c15f5847 Reviewed-on: https://gerrit.instructure.com/110497 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2017-05-03 00:44:54 +08:00
"build": "yarn run build:css && yarn run build:js",
speed up JS tests by running them concurrently closes: CORE-865 In order to get accurate coverage reports (ie: so the coverage numbers don’t only reflect a fraction of the total tests), when the COVERAGE environment variable is set, it does not split them out into groups to run concurrently. That way our linters-and-js-master build (which sets that environment variable) will run the same as it always has and our patch-set builds (which run the linters-and-js) will be faster. Test plan: * run ‘yarn test’ * it should be a lot faster than it used to be * look at the linters-and-js build in jenkins for this commit * it should have test reports for all both groups (coffee, js) Of karma tests as well as for the jest tests. * look at the coverage report after this gets merged. It should be the same as it was before Change-Id: I35147cc84df4afae92c1a73c201667d4d44b5518 Reviewed-on: https://gerrit.instructure.com/136373 Reviewed-by: Simon Williams <simon@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Reviewed-by: Jeremy Neander <jneander@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-22 04:09:17 +08:00
"build:watch": "concurrently \"yarn build:css:watch\" \"yarn build:js:watch\"",
make npm build scripts more user friendly :) test plan: - run the following commands and assess that they run as expected: - yarn run build - yarn run build:css - yarn run build:css:watch - yarn run build:js - yarn run build:jss:watch Change-Id: I4c0a2a68ce62896364bc2da5e7956002c15f5847 Reviewed-on: https://gerrit.instructure.com/110497 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2017-05-03 00:44:54 +08:00
"build:css": "brandable_css",
"build:css:watch": "brandable_css --watch",
"build:js": "yarn run webpack-development",
"build:js:watch": "yarn run webpack",
Move planner under canvas-lms closes: CORE-949 this also upgrades us to use what was on canvas-planner master as of 1pm on 2/1/2018 (specifically 9569cc1) test plan: * canvas planner should work * all automated builds should pass Change-Id: Iecce81d640c8aacb79189e2b26946613a03d25f2 Reviewed-on: https://gerrit.instructure.com/135947 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-12-18 22:39:39 +08:00
"build:packages": "script/yarn-packages build",
eliminate the need to run karma & webpack separately TL;DR: running JS tests in canvas will be a lot faster & simpler What you need to know as a developer writing JS in canvas: Lets say you are working on the “dashboard_cards” feature, just run: `npm run jspec-watch spec/javascripts/jsx/dashboard_card` While you write code and it will have a watcher that catches any changes and re-runs just the dashboar_card specs if you save any file that went into it. It should run & reload in less than a few seconds. You can give it the path to a specific spec file or have it run an entire directory. Or, if you are working on something that might touch a lot of stuff, run: `npm run test-watch` and while you are changing stuff, it will run *all* the QUnit specs on any change. It should only take a couple seconds for webpack to process the file change and to reload the specs in the browser. Jenkins can now just run “npm test” for the webpack build. No need to bundle install then run rake tasks just to run js tests. This change also starts warning you when you have specs that take a long time to run (e.g.: https://cl.ly/2i1O3O0J1504). It turns out we have some *really* slow js specs (like selenium-level slow) so if you notice a slow spec that you our your team wrote, please fix it. Longer details: To test our JS in webpack, we used to 1. run webpack with an env var set so it only does our ember stuff 2. run karma against ember 3. run webpack again against all the rest of the specs canvas 4 run karma again against all the specs in canvas that took a long time. this change makes it so both the ember specs and the specs in the rest of canvas run all in the same karma. it also makes it so karma runs webpack itself. so you don’t need to run `npm run webpack-test && karma start` to run tests, just `npm run test` (which is just an alias to `karma start`). it also means there is now just one watcher (karma) instead of one for both webpack and karma. Closes: CNVS-34977 Test plan: * Jenkins builds should pass * Try running different variations of the commands up there in the description. They should work and be fast-ish. Change-Id: Ia97f9bfa3677763f218f5f02c9463344f180bc6c Reviewed-on: https://gerrit.instructure.com/102169 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-02-14 11:57:26 +08:00
"webpack": "gulp rev & webpack --progress --color --watch",
"webpack-development": "gulp rev & webpack --progress --color",
Generate JavaScript sourcemaps in production Resolves instructure/canvas-lms#1101 In production, generate separate sourcemap files so that bundles appear split into their original, un-obfuscated source files in browser devtools. Note: `source-map` generation on large projects can cause node/v8 to exhaust its memory allocation (see webpack/webpack#1914, webpack/webpack#2157). This is the reason for the change to package.json. In the future (e.g. when Canvas uses Node 8, or the NODE_OPTIONS feature is back-ported to Node 6, this can go back to a traditional npm script that doesn't directly invoke `node`. Test Plan: - Remove the `public/dist/webpack-*` directories. - Run `JS_BUILD_NO_UGLIFY=true npm run webpack-production`. No sourcemap files should be present in `public/dist/webpack-production`. - Run `npm run webpack-production`. Sourcemap files should be present in `public/dist/webpack-production` Change-Id: Iebc85b5f52a6c7c25fdc5c2326cf9436dd42c2dd Reviewed-on: https://gerrit.instructure.com/128070 Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> Tested-by: Jenkins Reviewed-by: Simon Williams <simon@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2017-08-26 14:33:18 +08:00
"webpack-production": "NODE_ENV=production gulp rev & node --max_old_space_size=4096 $(yarn bin)/webpack --color --config webpack.production.config.js",
add npm script that can run specific js specs example usage: `npm run jspec spec/javascripts/jsx/files` refs CNVS-33223 test plan: - current webpack test build should work exactly the same - `npm run jspec` should build + run all specs - `npm run jspec path/to/stuff` should build + run only specified specs - should work with both directories and individual files - `jspec-watch` should watch + build a path, but not run specs Change-Id: I788dd38a6c69a4c36a1300fcecf43678bc7f5327 Reviewed-on: https://gerrit.instructure.com/94625 Tested-by: Jenkins Reviewed-by: Steven Burnett <sburnett@instructure.com> Product-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com> QA-Review: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
2016-11-08 05:13:53 +08:00
"jspec": "./spec/jspec.sh",
spec: add aXe unit testing capability this patch updates the a11y helper, adds a new spec script to run, and adds aXe testing to discussion views test plan: - run the spec files edited in this patch normally with yarn run jspec-watch path/to/spec - tests should all pass as expected - run the spec files edited in this patch with the new command yarn run a11y-report path/to/spec - you should get aXe errors on existing a11y violations Change-Id: Ib3db892046e115bedb363752d1e56226eef893af Reviewed-on: https://gerrit.instructure.com/87962 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins Product-Review: Matt Berns <mberns@instructure.com> QA-Review: Matt Berns <mberns@instructure.com>
2016-08-17 05:30:29 +08:00
"jspec-watch": "./spec/jspec.sh --watch",
script to upgrade without adding dupes to yarn.lock because yarn is silly and frequently adds duplicate entries for things into yarn.lock when it could satisfy everything the app needs with one version; when you make any changes to package.json, run this script: `yarn upgrade-and-dedupe` to make sure that yarn.lock doesn't add needless duplicates of things. if yarn ever fixes this issue: https://github.com/yarnpkg/yarn/issues/579 then this can go away. test plan: 1. check this out 2. run `yarn upgrade-and-dedupe` 3. push the change that commit makes 4. it should pass jenkins and not introduce any errors Change-Id: I8c268cc4c7c6ac4474221ce65129a6ef8b261813 Reviewed-on: https://gerrit.instructure.com/142447 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2018-03-03 02:20:00 +08:00
"a11y-report": "./spec/jspec.sh --a11y",
"upgrade-and-dedupe": "rm -rf yarn.lock node_modules && yes 1 | yarn install --flat --production && git checkout package.json && yarn install && git add yarn.lock && git commit -m 'update npm deps'"
make it so it works with yarn 1.3.2 (frd) closes: CORE-675 test plan: * while running yarn 0.27, * run `yarn` * it should work and there should only be one jquery in node_modules * brew upgrade yarn (or whatever else you do to upgrade yarn to 1.3.2) * run `yarn` * it should not log any warning about unpacking jquery to the same location as something else * it should work and not make any changes to yarn.lock or node_modules * load the calendar page, there should not be any errors Change-Id: I08a1b8ceddf31cae59720270f870516ad213b87d Reviewed-on: https://gerrit.instructure.com/133548 Tested-by: Jenkins Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2017-11-22 07:09:15 +08:00
},
"resolutions": {
"jquery": "https://github.com/ryankshaw/jquery.git#a755a3e9c99d5a70d8ea570836f94ae1ba56046d"
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
}
}