canvas-lms/package.json

148 lines
4.6 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",
"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",
"engines": {
"node": ">=6.9.5"
},
"dependencies": {
"brandable_css": "0.0.68",
"canvas_offline_course_viewer": "https://github.com/instructure/canvas_offline_course_viewer.git#0.2.1",
"fullcalendar": "https://github.com/ryankshaw/fullcalendar.git#aa686b36d10cee1e1e3ec7c7784145e46667d47d",
"instructure-icons": "1.2.1",
"instructure-ui": "1.0.2",
"tinymce": "4.1.9"
},
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": {
"axe-core": "2.1.7",
"axios": "0.15.2",
"babel-cli": "^6.10.1",
"babel-core": "^6.10.4",
"babel-eslint": "^7.1.0",
"babel-loader": "^6.2.4",
"babel-plugin-add-module-exports": "0.2.1",
"babel-polyfill": "6.22.0",
"babel-preset-es2015": "^6.9.0",
"babel-preset-react": "^6.11.1",
"babel-preset-stage-1": "^6.5.0",
"babel-register": "^6.9.0",
"backbone": "1.1.1",
"classnames": "~2.2.5",
"coffee-loader": "^0.7.2",
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
"coffee-script": "1.6.2",
"color-slicer": "0.8.0",
"core-js-builder": "^2.4.1",
Replace avatar image cropper with keyboard accessible one Fixes: CNVS-28306 Test Plan: - ensure Admin > <your account> > Settings > Enable Profiles and User Avatars are checked - navigate to Account > Profile - using keyboard: - TAB (displays "skip to main content") - ENTER (focuses on the main content of the profile page - TAB (focuses avatar image) - ENTER (displayes Select Profile Picture dialog) - TAB 4 times (focuses "choose a picture") - ENTER (displays system file open dialog) - Select a photo - The selected photo and crop-box are displayed and have focus - Use arrow keys to move the crop box around - Use shift-arrow keys to size the crop box - TAB twice to focus Save button - ENTER closes dialog - cropped image should be displayed on the profile page change history - added js spec for the cropper - fix require_js config for react-crop 2016-12-13 - changes needed after react-crop distribution changed - break CanvasCropper and CanvasCropperMaker into 2 files in response to code review 2016-12-16 - update the react-crop version - set a min size on the cropper (so it can't go negative) - update css so image won't overflow its box - address eslint warnings 2016-12-21 - fix merge conflict note: the .rb file change supports the build. there is no need for a corresponding spec Change-Id: I2b6dc165ed5dc2865f282c35018686dd820fea30 Reviewed-on: https://gerrit.instructure.com/97197 Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: David Tan <dtan@instructure.com> Product-Review: Chris Ward <cward@instructure.com> Tested-by: Jenkins
2016-12-10 00:05:18 +08:00
"css-loader": "0.26.1",
"d3": "3.4.1",
"ember-template-compiler": "^1.8.0",
"enzyme": "2.7.1",
"eslint": "^3.13.0",
"eslint-config-airbnb": "^14.0.0",
"eslint-config-airbnb-base": "^11.0.0",
"eslint-plugin-import": "^2.2.0",
"eslint-plugin-jsx-a11y": "^3.0.2",
"eslint-plugin-promise": "^3.4.0",
"eslint-plugin-react": "^6.9.0",
"exports-loader": "^0.6.2",
"expose-loader": "^0.7.0",
"fontfaceobserver": "^2.0.8",
"gglobby": "0.0.3",
"glob": "^7.0.3",
A new way of doing css/sass & New Canvas Theme Editor what this does: * Changes the way we generate css so we are able to generate custom css for people that use the theme editor. * Sets everything up so we can push all of our static assets (js, fonts, css, images, etc) to s3 pre-deploy and serve them from cloudfront. Yay! faster canvas for everyone! * as part of that, this enables the rails asset pipeline just so we can use it to put md5s in our urls. we don't use it for any of the coffeescript/sass/sprockets transformer stuff. * adds a new "Theme editor" functionality (only for people that have have the use-new-styles feature flag turned on) where an admin for an account can pick their own colors/images for all the users at their account/school. * when the user is done saving things in theme editor, it will, in a delayed job, generate all the css with against the variables that user specified and push it to s3 so it will be available to anyone else that requests it. (the delayed job will shell out to a node.js executable called `brandable_css`). * ability to pick an existing shared theme and to reset to blank theme. closes: CNVS-19685 * gets rid of jammit. test plan: (this is exaustive, so not every person has to do every step but we should make sure at least someone does each of these things. maybe as part of the review add a comment if you have done one of these bulletpoints) * before you check this out, compile all css and copy the public/stylsheets_compiled directory somewhere. after you check out this code and regenerate all the css. make sure there are no significant changes to the css output. (we updated the versions of node-sass and autoprefixer that we use so we want to make sure they don't change things in a way we weren't expecting) * make sure the way we load css for handlebars templates still works. eg: if there is a handlebars template at app/views/jst/some/template.handlebars if there is also a scss file at app/stylesheets/jst/some/template.scss then that stylesheet should get loaded when that template is rendered * check out the code and run migrations. browse around canvas, make sure css and js files load correctly as before. * cody, jacob, or someone on queso: look at the db migrations and make sure everything looks good and that I am handling sharding correctly. * verify that both rake canvas:compile_assets and guard, works as well as `node_modules/.bin/brandable_css` (note: if you have "node_modules/.bin" in your PATH (which you should), it will also work with just `brandable_css`) * verify that passing the --watch option to `.bin/node_modules/brandable_css` works and picks up changes to sass files, images, fonts, or any other resource that goes into a css file. and that it only recompiles the css files that actually depend on that file. * go to https://github.com/ryankshaw/brandable_css and check out the code there. that is what is actually doing the sass compiling * create a config/canvas_cdn.yml file and add aws access creds and an s3 bucket and cdn hostname (for testing, you can use the credentials for instructure_uploads_engineering from https://gollum.instructure.com/OtherServiceTestAccounts ). for a test cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that is a cloudfront bucket I set up on my personal account that points to instructure_uploads_engineering * run rake canvas:compile_assets again, this time, at the end, you should see it run the assets:precompile task that puts md5s in filenames and, gzipps them, and copys them to public/assets. then you should see it run canvas:cdn:upload_to_s3 (look at log/development.log for progress), which pushes everything to s3. closes: CNVS-17333 CNVS-17430 CNVS-17337 * try out the theme editor: turn on new styles, go to accounts/x (where x is the @domain root acount you are testing from) and click the "theme editor" button on the right side of the page. that should take you to a page that has the ability to pick colors/images on the left side and preview your changes in an iframe on the right closes: CNVS-19360 CNVS-20551 * test the "preview", "save", "reset", and "choose existing" functionality closes: CNVS-17339 CNVS-17338 CNVS-19685 * make sure that the themeeditor works both if you have config/canvas_cdn.yml set up and enabled as well as if you don't. if it is enabled, you should see it push the css for just that new brand config to s3 when you hit preview, and the css should be accessible from the cdn you configured. Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22 Reviewed-on: https://gerrit.instructure.com/53873 Tested-by: Jenkins QA-Review: Jeremy Putnam <jeremyp@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
"gulp": "^3.9",
"gulp-load-plugins": "^1.5.0",
"gulp-rev": "^7.0.0",
"handlebars": "1.3.0",
"handlebars-loader": "^1.1.4",
"happypack": "^3.0.2",
"ic-ajax": "~2.0.1",
"ic-tabs": "0.1.3",
"imports-loader": "0.7.0",
"istanbul-instrumenter-loader": "0.2.0",
"json-loader": "^0.5.3",
"jsx-loader": "0.11.2",
"karma": "1.3.0",
"karma-chrome-launcher": "^2.0.0",
"karma-coverage": "1.1.1",
"karma-firework-reporter": "~0.2.4",
"karma-phantomjs-launcher": "^1.0.0",
"karma-qunit": "~1.1.0",
"karma-sourcemap-loader": "^0.3.7",
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
"karma-verbose-reporter": "^0.0.5",
"karma-webpack": "^2.0.2",
"phantomjs-prebuilt": "^2.1.4",
"qunitjs": "^1.14.0",
"script-loader": "^0.7.0",
"sinon": "2.0.0-pre.5",
Replace avatar image cropper with keyboard accessible one Fixes: CNVS-28306 Test Plan: - ensure Admin > <your account> > Settings > Enable Profiles and User Avatars are checked - navigate to Account > Profile - using keyboard: - TAB (displays "skip to main content") - ENTER (focuses on the main content of the profile page - TAB (focuses avatar image) - ENTER (displayes Select Profile Picture dialog) - TAB 4 times (focuses "choose a picture") - ENTER (displays system file open dialog) - Select a photo - The selected photo and crop-box are displayed and have focus - Use arrow keys to move the crop box around - Use shift-arrow keys to size the crop box - TAB twice to focus Save button - ENTER closes dialog - cropped image should be displayed on the profile page change history - added js spec for the cropper - fix require_js config for react-crop 2016-12-13 - changes needed after react-crop distribution changed - break CanvasCropper and CanvasCropperMaker into 2 files in response to code review 2016-12-16 - update the react-crop version - set a min size on the cropper (so it can't go negative) - update css so image won't overflow its box - address eslint warnings 2016-12-21 - fix merge conflict note: the .rb file change supports the build. there is no need for a corresponding spec Change-Id: I2b6dc165ed5dc2865f282c35018686dd820fea30 Reviewed-on: https://gerrit.instructure.com/97197 Reviewed-by: Steven Burnett <sburnett@instructure.com> QA-Review: David Tan <dtan@instructure.com> Product-Review: Chris Ward <cward@instructure.com> Tested-by: Jenkins
2016-12-10 00:05:18 +08:00
"style-loader": "^0.13.1",
"stylelint": "7.8.0",
"timezone": "1.0.5",
"uglify-js": "~2.7.0",
"webpack": "2.2.1",
Webpack: better handling of chunks and cdn stuff fixes: CNVS-31779 [webpack] bundle file size test plan: * using webpack, look at the network panel in the chrome developer console. * the total ammount of javascript loaded for any given page should be much less than before this commit and about on par with what requireJS loads for the same page. * use chrome network panel to throttle to "Regular 3G" * from both a clean cache and a primed cache: * make sure that the total time to render the page is about on par with requireJS first change: load webpack chunks from CDN fixes: CNVS-32261 test plan: * run `npm run webpack-production` * check your page, it should load js files and chunks from the same hostname the page is served from. * now set a host: in config/canvas_cdn.yml (for testing locally, I just set it to http://127.0.0.1:3000, * restart rails and reload the page, now the scripts and chucks should come from that new hostname second change:include fingerprints in webpack bundle and chunk filenames closes: CNVS-28628 with this change we don't need to run `gulp rev` after running webpack and we can load both the bundle and chunk files safely from the cdn, since they will have content-based fingerprints so we can tell browsers to cache them forever. (we set those http caching headers in lib/canvas/cdn/s3_uploader.rb:53) test plan: * for both dev and production * run `npm run webpack` (or `npm run wepack-production`) * with a cdn configured in canvas_cdn.yml, run: RAILS_ENV=<dev or prod> bundle exec rake canvas:cdn:upload_to_s3 * check to make sure that the page loads the webpack js, that there are no errors, and it all came from the cdn third change: properly handle moment locale & timezone in webpack test plan: (see application_helper_spec.rb) * set a non-default user timezone, context timezone and locale * dates should show up in your timezone and and the date helper strings should be in your language better handling of moment custom locales closes: CNVS-33811 since we now have hatian and maori, we need to do this in a way that is not just a one-off for maori test plan: * set your locale to maori * in webpack & requireJS make sure dates show up right Change-Id: I34dbff7d46a1047f9b459d5e1c0d141f435d42fb Reviewed-on: https://gerrit.instructure.com/95737 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2016-12-13 01:32:11 +08:00
"webpack-manifest-plugin": "^1.0.1",
"webpack-parallel-uglify-plugin": "0.2.0",
"xsslint": "0.1.4",
"backbone": "1.1.1",
"classnames": "~2.2.5",
"color-slicer": "0.8.0",
"d3": "3.4.1",
"fontfaceobserver": "^2.0.8",
"handlebars": "1.3.0",
"ic-ajax": "~2.0.1",
"ic-tabs": "0.1.3",
"lodash": "4.16.4",
"moment": "~2.10.6",
Webpack: better handling of chunks and cdn stuff fixes: CNVS-31779 [webpack] bundle file size test plan: * using webpack, look at the network panel in the chrome developer console. * the total ammount of javascript loaded for any given page should be much less than before this commit and about on par with what requireJS loads for the same page. * use chrome network panel to throttle to "Regular 3G" * from both a clean cache and a primed cache: * make sure that the total time to render the page is about on par with requireJS first change: load webpack chunks from CDN fixes: CNVS-32261 test plan: * run `npm run webpack-production` * check your page, it should load js files and chunks from the same hostname the page is served from. * now set a host: in config/canvas_cdn.yml (for testing locally, I just set it to http://127.0.0.1:3000, * restart rails and reload the page, now the scripts and chucks should come from that new hostname second change:include fingerprints in webpack bundle and chunk filenames closes: CNVS-28628 with this change we don't need to run `gulp rev` after running webpack and we can load both the bundle and chunk files safely from the cdn, since they will have content-based fingerprints so we can tell browsers to cache them forever. (we set those http caching headers in lib/canvas/cdn/s3_uploader.rb:53) test plan: * for both dev and production * run `npm run webpack` (or `npm run wepack-production`) * with a cdn configured in canvas_cdn.yml, run: RAILS_ENV=<dev or prod> bundle exec rake canvas:cdn:upload_to_s3 * check to make sure that the page loads the webpack js, that there are no errors, and it all came from the cdn third change: properly handle moment locale & timezone in webpack test plan: (see application_helper_spec.rb) * set a non-default user timezone, context timezone and locale * dates should show up in your timezone and and the date helper strings should be in your language better handling of moment custom locales closes: CNVS-33811 since we now have hatian and maori, we need to do this in a way that is not just a one-off for maori test plan: * set your locale to maori * in webpack & requireJS make sure dates show up right Change-Id: I34dbff7d46a1047f9b459d5e1c0d141f435d42fb Reviewed-on: https://gerrit.instructure.com/95737 Reviewed-by: Clay Diffrient <cdiffrient@instructure.com> Tested-by: Jenkins QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2016-12-13 01:32:11 +08:00
"moxios": "^0.3.0",
"page": "visionmedia/page.js#1.6.4",
"parse-decimal-number": "0.1.1",
"phantomjs-prebuilt": "^2.1.4",
"qs": "https://github.com/hapijs/qs.git#a341cdf2fadba5ede1ce6c95c7051f6f31f37b81",
"qunitjs": "^1.14.0",
"react": "0.14.8",
"react-addons-css-transition-group": "0.14.8",
"react-addons-pure-render-mixin": "0.14.8",
"react-addons-test-utils": "0.14.8",
"react-addons-update": "0.14.8",
"react-crop": "^4.0.2",
"react-dnd": "2.1.4",
"react-dnd-html5-backend": "2.1.2",
"react-dom": "0.14.8",
"react-modal": "1.6.5",
"react-redux": "4.4.5",
"react-select-box": "https://github.com/instructure-react/react-select-box.git#b1ddd39223d48793fbe3dc4e87aca00d57197b5f",
"react-tabs": "0.8.2",
Improve accessibility when assigning students fixes OUT-389 1. Indicate to non-visual users which students are currently assigned to an assignment when they navigate to the delete label of a button. 2. Customized the aria label associated with the Assign To auto-complete search field to improve clarity and conciseness. 3. When navigating through assigned students, read the button label first before reading the delete label. 4. Added an instructional element before reaching the Assign To field that is spoken to screen reader users that are only using directional keys to navigate with. test plan: - enable a screen reader - open the new assignment page - using directional keys only, navigate to the "Assign To" label - press the down arrow key and confirm that the screen reader speaks "Use this list to remove...". You may need to press the down arrow key again to speak the complete message. - press the down arrow key and confirm that the first label is read - press the down arrow key and confirm that the delete label is read, which starts off with "Currently assigned to ... click to remove" - starting in the Moderated Grading section, using the tab key, tab to the Assign section - confirm that when focus is on the delete portion of the Everyone element, that the screen reader reads "Currently assigned to ..." - press the tab key to navigate to the auto-complete portion of the field - confirm that the screen reader speaks "Add students by searching ..." Change-Id: I2be0fd4662bd0d196f27d1dbb59b09edb7be9e3a Reviewed-on: https://gerrit.instructure.com/93517 Reviewed-by: Christian Prescott <cprescott@instructure.com> Tested-by: Jenkins QA-Review: Cemal Aktas <caktas@instructure.com> Product-Review: Nathan Rogowski <nathan@instructure.com>
2016-10-18 06:17:42 +08:00
"react-tokeninput": "2.2.2",
"react-tray": "2.0.4",
"redux": "3.5.2",
"redux-actions": "0.11.0",
"redux-logger": "2.6.1",
"redux-thunk": "2.1.0",
"requirejs": "~2.2.0",
"script-loader": "^0.7.0",
"sinon": "2.0.0-pre.5",
"spin.js": "2.3.2",
"style-loader": "^0.13.1",
"stylelint": "7.8.0",
"timezone": "1.0.5",
"uglify-js": "~2.7.0",
"webpack": "2.2.1",
"webpack-manifest-plugin": "^1.0.1",
"webpack-parallel-uglify-plugin": "0.2.0"
},
"repository": "instructure/canvas-lms",
"scripts": {
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
"test": "karma start --single-run",
"test-watch": "karma start",
"preinstall": "script/gem_npm install",
"preupdate": "script/gem_npm update",
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",
"webpack-stats": "webpack --profile --json",
"webpack-production": "gulp rev & webpack --progress --color --config webpack.production.config.js",
"jspec": "./spec/jspec.sh",
"jspec-watch": "./spec/jspec.sh --watch"
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
}
}