also includes a helper to validate number strings for current locale
closes CNVS-33191
test plan:
- NA (a future commit demonstrating the use of the helper with be
qa-able)
Change-Id: I1722aad263e611d127317b2f1a3832537742c3fb
Reviewed-on: https://gerrit.instructure.com/96677
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Brent Burgoyne <bburgoyne@instructure.com>
goes really well with the jspec script
test plan:
- builds pass
Change-Id: If596d5f1983957eb9862021b8abaaf8f80c747c1
Reviewed-on: https://gerrit.instructure.com/96454
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>
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>
closes: CNVS-32953
This commit re-introduces Instructure Icons into Canvas.
Due to the range in aesthetic impact of including both line
and solid icons, the change is expansive and will be refined
in subsequent commits. The purpose of this commit is to:
- Make InstIcons available in Canvas allowing the use of the
react components
- Replace the current icon font with the new InstIcons font
- Allow for use of both 'Line' and 'Solid' icon variants
- Update the styleguide to reference the InstIcons github
documentation for examples
- Remove font custom from Canvas
Icons changed to line versions in Canvas:
- icon-compose (view on Dashboard card)
- icon-info (view on global notification)
- Updated icons to be larger for better visibility
(our old font was using a small font size)
- Updated font-size is now relative vs fixed, so better a11y
Test Plan:
- On compiling, icons in Canvas should now be changed to the
corresponding Instructure Icons as can be seen here
http://instructure.github.io/instructure-icons/
- The icon default displaying in Canvas should be solid icons.
If the variant "icon-Line" is added to an icon's css class,
it should display as line. For example, in the case of
<i class="icon-edit"></i>, adding
<i class="icon-edit icon-Line"></i> would result in a line
version of the edit icon displaying
- As a developer, you should be able to use InstUI react icons
- The rake task `bundle exec rake icons:compile` should no
longer exist
- The styleguide should no longer display example icons, but
should now include a link to the Instructure Icons github
documentation
Change-Id: I9780332de9fdf937b35caabadc2b2ee615892a43
Reviewed-on: https://gerrit.instructure.com/94175
Reviewed-by: Pam Hiett <phiett@instructure.com>
QA-Review: Dan Sasaki
Tested-by: Jenkins
Product-Review: Kyle Follett <kfollett@instructure.com>
This commit also cleans things up a bit to make things more inline
with our current JS style preferences.
Test Plan:
- Specs pass
Change-Id: Idf1af11b4283844017552df62963a7740bb7f609
Reviewed-on: https://gerrit.instructure.com/95637
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
NOTE: This commit does not make it so that the data
persists after refreshes.
closes CNVS-32548
Test Plan:
- Enable dashboard card reordering feature flag
- Go to a dashboard with multiple dashcards
- You should be able to move them around via drag
and drop.
Change-Id: I66b91b30fd619516558841a6867ef857a33b890a
Reviewed-on: https://gerrit.instructure.com/92616
Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Fixes: CNVS-30278
The product design team wants to standardize
on Lato across all Instructure products. See
JIRA for more information.
With this change, we no longer have to use
font-weight: 300 etc to make the right
weight of Helvetica show up. We can go back
to simply using bold and normal, etc.; so
those rules have been updated in this
commit.
Test plan:
to accurately test this you need to set up your
canvas to use a CDN. there is a dev CDN that ops
has set up for us. you put the settings in
config/canvas_cdn.yml. slack ryan if you need help
setting that up or need to know what the values
are to use.
you also need to edit your config/environments/development.rb
file so it look like this:
config.action_controller.perform_caching = true
ENV['USE_OPTIMIZED_JS'] = 'true'
and then when you make any changes you need to run:
bundle exec rake canvas:compile_assets
bundle exec rake canvas:cdn:upload_to_s3
touch tmp/restart.txt
for the changes to be seen
- This change applies only to new UI. Legacy
should be unchanged.
- Clear cache and cookies first.
- Go to Canvas. On the first page load only
you should see a slight shifting of the text
as Canvas loads the Lato font and falls
back on the Helvetica system font.
- From that point on, Lato should be
cached in the browser and load instantly
when you move between views:
http://screencast.com/t/hZhUZOhH
- Canvas should still work in all supported
languages and browsers.
Not yet converted:
- TinyMCE textarea fiekd
- Mobile login
Change-Id: I861e609c01824f60ac38d3fc15e5b960a06e44de
Reviewed-on: https://gerrit.instructure.com/85737
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
QA-Review: Dan Sasaki
Product-Review: Kyle Follett <kfollett@instructure.com>
This removes the ill-fated React Gradebook.
This commit is effectively a revert of
b9534edd64
closes CNVS-32394
test plan:
* ensure 'Gradebook Performance' is no longer available
* ensure other Gradebooks are still functional
* Default Gradebook basic happy path
* Individual Gradebook (SRGB) basic happy path
Change-Id: Ie71ab4dfb17f494c2a7c17a27cd551a84e7efb96
Reviewed-on: https://gerrit.instructure.com/94005
Tested-by: Jenkins
Reviewed-by: Spencer Olson <solson@instructure.com>
QA-Review: KC Naegle <knaegle@instructure.com>
Product-Review: Christi Wruck
since we're on node 6.6 now, we don't need
babel for anything we were using it for in our
frontend build/webpack code that runs on node.
(except for es6 import/export)
Change-Id: I41352fdc8adb06fe1585565f63d808d249f92864
Reviewed-on: https://gerrit.instructure.com/91573
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
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>
Rollout plan for this:
1. Add necessary files and plugins to Canvas (this commit)
- This will do nothing for many people, but those with eslint
plugins in their editors will now start seeing linting stuff
show up properly
- These users can gradually add/remove rules as they see fit or
where it makes sense. The default rule set is from Airbnb with
a few minor modifications to make things less difficult with the
current codebase.
2. Turn on warnings in the CI system (this commit + 1-2 months)
- This would only apply to the diffs of new code
- This will allow additional feedback from developers that don't
already lint locally. Rules can be adjusted as seen fit.
3. Turn on failures in the CI system (this commit + 3-4 months)
- Again this will be only for changed code, but at this point will
start failing builds that don't follow the standards.
- Changes to the rules can still be made here, but should be less
frequent than those made in the previous 2 steps.
closes CNVS-32987
Test Plan:
- Running eslint locally works
- Editors pick up linting errors when configured properly
Change-Id: I93b7da735b96b472857120418c3c271a9ed6d429
Reviewed-on: https://gerrit.instructure.com/93969
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
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>
This reverts commit ce771d353b.
fixes CNVS-32874
test plan:
- make sure that old icons are working appropriately, especially with
inst-ui components
Change-Id: If749cec08302b1bd252c0938ad9fd2329e1c1040
Reviewed-on: https://gerrit.instructure.com/93540
Reviewed-by: Colleen Palmer <colleen@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
Tested-by: Jenkins
QA-Review: Pierce Arner <pierce@instructure.com>
test plan:
* add an invalid hex code to a scss file
e.g. _variables.scss:
color: #YARRRRRRRR
* run stylelint with: `script/stylelint`
* verify the colored output only returns your introduced error
Change-Id: Ia4f2adef3635f34154d50d61249b952a380208bf
Reviewed-on: https://gerrit.instructure.com/92229
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
fixes CNVS-32581, CNVS-32619, CNVS-32652
Test Plan:
- npm install should give version 0.16.0 of instructure-ui package
Change-Id: Iea942adf2da251ea06ad19844eee8df21b8fb95b
Reviewed-on: https://gerrit.instructure.com/92784
Reviewed-by: Stephen Jensen <sejensen@instructure.com>
Product-Review: Stephen Jensen <sejensen@instructure.com>
Tested-by: Jenkins
QA-Review: Pedro Fajardo <pfajardo@instructure.com>
closes: CNVS-29706
This initial commit introduces Instructure Icons into Canvas.
Due to the range in aesthetic impact of including both line
and solid icons, the change is expansive and will be refined
in subsequent commits. The purpose of this commit is to:
- Make InstIcons available in Canvas allowing the use of the
react components
- Replace the current icon font with the new InstIcons font
- Allow for use of both 'Line' and 'Solid' icon variants
- Update the styleguide to reference the InstIcons github
documentation for examples
- Remove font custom from Canvas
Test Plan:
- On compiling, icons in Canvas should now be changed to the
corresponding Instructure Icons as can be seen here
http://instructure.github.io/instructure-icons/
- The icon default displaying in Canvas should be solid icons.
If the variant "icon-Line" is added to an icon's css class,
it should display as line. For example, in the case of
<i class="icon-edit"></i>, adding
<i class="icon-edit icon-Line"></i> would result in a line
version of the edit icon displaying
- As a developer, you should be able to use InstUI react icons
- The rake task `bundle exec rake icons:compile` should no
longer exist
- The styleguide should no longer display example icons, but
should now include a link to the Instructure Icons github
documentation
Change-Id: Id5a2f7be33b8e5bed76867da067309d044b5be06
Reviewed-on: https://gerrit.instructure.com/91014
Tested-by: Jenkins
QA-Review: Pierce Arner <pierce@instructure.com>
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Product-Review: Jennifer Stern <jstern@instructure.com>
Product-Review: Kyle Follett <kfollett@instructure.com>
fixes CNVS-31803
test plan:
- take a quiz with several students
and get different scores
- go to the quiz statistics page
- with a screenreader go to the chart
showing the breakdown of scores
by percentile
- you get a description of the bars
in the screenreader (X students in
percentile Y)
Change-Id: I100577687058d27a9921773e81edc64b3cf1cb87
Reviewed-on: https://gerrit.instructure.com/90642
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
Tested-by: Jenkins
QA-Review: Robin Kuss <rkuss@instructure.com>
Product-Review: Nathan Rogowski <nathan@instructure.com>
fixes CNVS-31926
Also note: we no longer want to load all of InstUI at once, and instead
prefer to load components as we need them.
Test plan:
* automated tests pass
Change-Id: Ia3b73bd68c94901da64c432ab88f3b7a1634a77f
Reviewed-on: https://gerrit.instructure.com/90271
Reviewed-by: Michael Brewer-Davis <mbd@instructure.com>
Tested-by: Jenkins
Product-Review: Colleen Palmer <colleen@instructure.com>
QA-Review: Colleen Palmer <colleen@instructure.com>
closes: CNVS-31621
every other browser supports these features.
this will just make it so we can count on things
like Promise, Object.assign, [].includes etc (see
FEATURES_TO_POLYFILL at the top of
script/make-ie11-shim.js for full list)
what do people think of this? what do you think of the
approach, I don't want to include a polyfill in the
common bundle and force every other browser to download
this stuff they aren't going to need. but I still want
it to be performant as possible for those using ie11
Is there anything else people think we should polyfill?
the one I thought of is window.fetch, what do others
think about that?
test plan:
* in ie11, load a page in canvas
* open the IE developer console
* type: Promise.resolve().then(function(){console.log('it works')})
* it should log 'it works' to the console
* (that already works in other browsers, but you can
check to make sure that it still does there too)
Change-Id: Ie9c99a59631a13535903174a5e575427dbfeac4f
Reviewed-on: https://gerrit.instructure.com/89626
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
When using webpack, we pack up everything outside of karma and
assuming you've set webpack to generate source maps it doesn't actually
use them. This makes it so that it does use them so output can
be much better.
Test Plan:
- Have your environment set up to use webpack
- Change webpack.test.config.babel.js:23 to be:
testWebpackConfig.devtool = 'inline-source-map';
- Comment out lines 64-68 of the same file
- Run npm run webpack-test-watch to bundle the
tests
- Run the specs (doc/testing_javascript.md)
- Make a test fail... you should see a mapping
from bundled test file to the actual file.
Change-Id: I650fe995d6aa595d89da5ae614d5407a699e75ec
Reviewed-on: https://gerrit.instructure.com/89822
Tested-by: Jenkins
Reviewed-by: Joel Hough <joel@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
closes: CNVS-29725
this gets everything working on node 6.
As far as our build process goes, it cannot support
running on both node 6 at the same time as 0.12
since our i18nliner handlebars stuff uses jsdom and
one version of it only works on node <4 and the
next only works on 4+.
But the stuff in the production dependencies in
package.json, aka the stuff that runs on the job
servers (brandable_css), can work on both. we just
need to run npm rebuild on the job servers if the stuff
that was npm installed into ./node_modules was compiled
against a different version of node. that is done here:
https://gerrit.instructure.com/81254
that commit needs to be committed to caturday before
we commit and deploy this to beta
as far as managing node, there are 2 "official"
ways that will make you life easier, you can either
just use docker or use nvm (https://github.com/creationix/nvm)
if you use nvm and if you use ZSH:
Put this into your $HOME/.zshrc to call nvm use automatically
whenever you enter a directory that contains an
.nvmrc file with a string telling nvm which node to use:
# place this after nvm initialization!
autoload -U add-zsh-hook
load-nvmrc() {
if [[ -f .nvmrc && -r .nvmrc ]]; then
nvm use
elif [[ $(nvm version) != $(nvm version default) ]]; then
echo "Reverting to nvm default version"
nvm use default
fi
}
add-zsh-hook chpwd load-nvmrc
load-nvmrc
but however you do it, as long as you have node 6.2
installed it should work
test plan:
* install nvm
* check this patchset out
* run bundle exec rake canvas:compile_assets
* it should work
* use theme editor to preview a change to a theme
* it should work
Change-Id: I1cc9faed361938afc713c4b921042386b956db70
Reviewed-on: https://gerrit.instructure.com/80839
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
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>
fixes: CNVS-30802
these are the npm deps I upgraded as part of my
node 6 commit that should work fine on both node
0.12 and node 6. I am making this change as a separate
commit so you can see exactly which ones only work
on node 6 (or 0.12, or vise-versa) by looking
at the package.json changes in the node 6 commit
test plan:
run npm install
it should work
Change-Id: I7fca4738ad3593caa7512ebb6be55866ea614af3
Reviewed-on: https://gerrit.instructure.com/87028
Tested-by: Jenkins
Reviewed-by: Brent Burgoyne <bburgoyne@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ian Hoerner <ian@instructure.com>
fixes: CNVS-30799
This updates us to the latest inst-ui, which addresses conflicts
instructure-ui.js had with requirejs.
TODO: once the next version of instructure-ui is released,
we should be able to delete public/javascripts/instructure-ui.js
and rename the public/javascripts/InstUI.js sym link to
instructure-ui.js (and update .xssignore and canvas.rake accordingly)
Change-Id: I3fd9f4bac0447c37754f9f85165ad05728672c1f
Reviewed-on: https://gerrit.instructure.com/87050
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Neil Gupta <ngupta@instructure.com>
QA-Review: Neil Gupta <ngupta@instructure.com>
fixes: CNVS-30799
...since it is not just needed for our build
tooling, it is actually needed in the actual app
because common.scss @import ../../../node_modules/instructure-ui/dist/instructure-ui
directly. so without having this in the prod
dependencies, it will blow up when someone
tries to preview in the theme editor and at deploy
time when we run brand_configs
test plan:
run these terminal commands:
* rm -rf node_modules
* npm install --production
* node_modules/.bin/brandable_css
those should work.
now open theme editor
make a change
hit preview
it should work
Change-Id: I87e9896e668d16b653e868bd202a807c204f2f95
Reviewed-on: https://gerrit.instructure.com/87027
Reviewed-by: Neil Gupta <ngupta@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-30588 for reals this time
test plan:
npm install --production should work on node 0.12.x
(the "--production" part is important here, since
it worked before for devDependencies but we want
to specifically test if it works just installing
prod dependencies)
Change-Id: I27d90db87f3be2891a8e04eb413f1cd7f30dd52f
Reviewed-on: https://gerrit.instructure.com/86151
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-30588
test plan:
npm install should work on node 0.12.x
Change-Id: Ic77bc68c649e14faa7cf89d4378f2520c023374e
Reviewed-on: https://gerrit.instructure.com/86129
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This prevents our gulpfile from printing out an error trying to
require babel-register before falling back to babel-core/register.
This is now possible because we are on Babel 6.
closes gh-867
Test Plan:
- Run compile assets
- At the end during the 'rev' step, you should not see:
```
Failed to load external module babel-register
Requiring external module babel-core/register
```
- Instead you should just see:
```
Requiring external module babel-register
```
Change-Id: I3168dbdfb733979e762537f40fdb96effbefa328
Reviewed-on: https://gerrit.instructure.com/85571
Tested-by: Jenkins
Reviewed-by: Steven Burnett <sburnett@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
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>
Fixes CNVS-30301
Test Plan:
- Running the js tests locally should generate
a folder called coverage-js with an index.html
file that has the coverage information
Change-Id: Ib57b40c60791324d0a1eafab4c541957a2c2e7e7
Reviewed-on: https://gerrit.instructure.com/84839
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins
Product-Review: Steven Burnett <sburnett@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
this was a blocker for upgrading to node 6 since
karma 0.x has a strict node version requirement
of <=4, so it would not work on node 6 (although,
ironically, if you forced it it would still work)
closes: CNVS-30308
test plan:
* run `npm install && bundle exec rake js:test`
* it should work
* the jenkins builds should all work
Change-Id: Ifd9ae12347d7901cf2bafee110230699987b2511
Reviewed-on: https://gerrit.instructure.com/84590
Tested-by: Jenkins
Reviewed-by: Matthew Sessions <msessions@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-29785
the newest versions of node-sass do not allow
@import inside an @if
also, this:
@if something { $foo: 'bar'}
@else { $foo: 'baz'}
// on this line foo is not supposed to exist,
//but it erroneously did in old node-sass and we relied on it
this blocks us from upgrading to node 6 because the
gcc on the jenkins and job boxes is to old to compile
node-sass 3.4 from source against the v8 in node 6. but
there are prebuilt binaries it can use for node-sass
3.7+, so it doesn't need to compile from source
test plan
* check out this commit
* compile assets
* it should work
* the css it outputs should be exactly the same as before
Change-Id: I797ce68ecc82566401076771784c8be590233e27
Reviewed-on: https://gerrit.instructure.com/81513
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
a couple things:
* our spec matcher was matching spec files in some of our
bower components and so it tried running those
tests, which obviously failed
* removed some cruft leftover from the switch from
testem to karma a long time ago
Change-Id: I61dc400bbfae0a679c698a90c7bcddd4fcf9fecc
Reviewed-on: https://gerrit.instructure.com/77908
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
fixes: CNVS-28888
by pinning node-sass to 3.4.2 in brandable_css
we avoid the bug introduced in 3.5.1 where
it won't allow us to @import inside an @if
test plan:
* run compile_assets
* css should look the same as before
Change-Id: I437afd60e4dde60e65d03de4deca5a67ef7e3897
Reviewed-on: https://gerrit.instructure.com/77639
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-27874
TEST PLAN:
1) run webpack build
2) should be fast
3) load the calendar page
4) all the styles should look good
Change-Id: I28d9205fbf53616ed9264d8393dc617962e43c22
Reviewed-on: https://gerrit.instructure.com/74197
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
refs: CNVS-27679
if you name your config files *.config.babel.js
webpack knows to run them through babel. this change
makes it so use es6 stuff in the webpack.config files
(including everything in /frontend_build)
test plan:
run webpack
it should work
Change-Id: I6ceda3386227c30e106339f744f18dc61bbab54b
Reviewed-on: https://gerrit.instructure.com/73241
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
refs CNVS-25916
Use an AMD-rewritten version of old react-router
and expose some of reacts internals that
react-router depends on (named AMD across files
is something web pack does not support), and leave
the other version for the require-js build for now.
Also, add gulp rev as a web pack post build action.
TEST PLAN:
1) regression check QLA and Quiz Stats
to make sure reworking their dependencies didn't
crash everything
Change-Id: Id2b448a334494ebd3d353678742bf07c1b7833eb
Reviewed-on: https://gerrit.instructure.com/69837
Tested-by: Jenkins
Reviewed-by: Ryan Taylor <rtaylor@instructure.com>
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
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>
closes CNVS-25714
TEST PLAN:
web pack should compile in like 60 seconds rather than 600
Change-Id: I74716d9cccfd0253693660c0b4ad4368e91b72e7
Reviewed-on: https://gerrit.instructure.com/68497
Tested-by: Jenkins
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-24966
change js specs to work with web pack.
update some dependency references, make some aliases
for external dependencies to get the right version,
and clean up a bunch of leaky state.
TEST PLAN:
js tests should pass in web pack _and_ requires
Change-Id: If37fbce93e7e67021d90bacb470ffc4f1b17402d
Reviewed-on: https://gerrit.instructure.com/66309
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
this pins the acorn version, so we have less strict `undefined` handling
test plan:
n/a, xsslint should pass again
Change-Id: I70ac1de7ce303ac23c70242e13933dbd5ab0c9d0
Reviewed-on: https://gerrit.instructure.com/66760
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
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>
the actual changes are in:
https://github.com/ryankshaw/brandable_css/compare/8cff7...master
make sure to review that too
first thing it fixes:
better logic for knowing what to skip in brandable_css
closes: CNVS-24039
* gets rid of any manifest files on s3.
The only manifest file that is used is the one
on the local disk which only includes metadata
about the "stock" (unbranded) css files which
are generated as part of the tarball on the
deployer's vm.
* which means we no longer use the env var:
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST
* because the filenames on s3 include:
<css bundle name>
<combined checksum of stock version of this file>,
<md5 of this brand config>
if that css file exists, we know we don't need
to generate or upload that file again. and we
don't need a shared manifest on s3 to figure that
all out.
test plan:
* with a canvas_cdn.yml file configured
* run brandable_css
* run it again, it should be fast
* rm -rf public/dist/brandable_css
* run it again, it should generate all the "stock"
(unbranded) css and skip all the brand configs
* change a value in variables.scss
* run it again, everything should be recompiled
also fixes: CNVS-24269 and CNVS-23786
to test:
* with a canvas_cdn.yml enabled and delayed jobs running
* go to theme editor for your account
* change a value to a non-default value
* press preview
* it should generate the preview correctly
(you should not see the giant svg icons)
* "apply" it, it should still not have the unstyled
giant svg icons
Change-Id: I992c11b392a0d6bbb045b16a78036f5ec1afed31
Reviewed-on: https://gerrit.instructure.com/65203
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
This replaces the deprecated JSX compiler formerly provided by
react-tools to use the Babel preprocessor.
This allows us to use ES6+ inside Canvas :)
Unfortunately, we had the jsx pragma hanging around all over the place
and Babel considers this an ERROR now... so I ripped them all out.
Babel also turns on strict mode for JS files, which means I needed
to fix a few things in other places to make it work such as duplicate
object keys and variables without declaration. DueDateTokenWrapper.jsx
had a problem with a 'this' being seen on the global level which Babel
detects to be nothing so it throws in an undefined. I reworked it so
that the function should still have the intended effect and 'this'
is properly scoped.
closes CNVS-24123
Test Plan
- Make sure all JSX compiles via Guard and via js:jsx rake task
- Make sure nothing is broken in any of the react-y areas of
Canvas.
Change-Id: I5ab8f7f435504f8269e2b7da96813337676cf175
Reviewed-on: https://gerrit.instructure.com/65451
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Tested-by: Jenkins
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
Now with full js/jsx/coffee/hbs/scss goodness \o/
If your commit ONLY touches js/jsx/coffee/hbs/scss/views/controllers or
specific whitelisted things, and doesn't touch global-y bundles or
layouts, then your commit may** be selinimized. That means it will only
run the selenium specs that care about those files.
If you touch lib, or gems, or models, or any global-y stuff, all the specs
will still run.
Also add the ability to override what we selinimize against when testing
changes to selinimum.
**Note that actual selinimization depends on a post-merge build having
succeeded for the parent (or a near ancestor). If the post-merge build
failed, or your build starts before it finishes, or there are
unselinimizable changes between your commit and the nearest ancestor with
selinimum stats, then your commit will not be selinimized :'(
See 4a83f6b6 for the full story.
Test Plan:
* Specs should pass on this commit
* It should not be selinimized because we touch package.json
* See dependent test commits where selinimization happens
Change-Id: I62c78c316876aaff07514a0f460ff4d608dac494
Reviewed-on: https://gerrit.instructure.com/65082
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
fixes: CNVS-23783
also closes: CNVS-23841
all the real changes are here:
https://github.com/ryankshaw/brandable_css/compare/2cf4ad3...master
review those too while you are reviewing this.
(sidenote: I was going to get this all set up to host
that npm package all official from the instructure
github account but, apparently we are going to get
our own private npm so I didn't want to go through
all of that fuss just to change it again when that
gets figured out)
https://gerrit.instructure.com/64465 should be
submitted along with this
test plan:
* bundle exec rake RAILS_ENV=production \
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST=some_unique_key \
brand_configs:generate_and_upload_all
* it should generate all your css from scratch
* run that again, it should say "no sass changes"
* bundle exec rake RAILS_ENV=production \
UNIQUE_KEY_FOR_BRANDABLE_CSS_MANIFEST=other_key \
brand_configs:generate_and_upload_all
* should generate everything from scratch
* https://dev-canvascdn1-com.s3.amazonaws.com/dist/brandable_css/brand
able_css_bundles_with_deps.jsonnestedother_key
should exist
to also test CNVS-23841:
* with node 0.11.x installed
* try to run `bundle exec canvas:compile_assets`
* it should fail fast and tell you it failed because
you don't have a new enough node
* it should not ambiguously fail with an error like
cannot find method 'parse' of undefined
Change-Id: I7a90560b8ef3c5ca173c4b5bc06e0681848c0099
Reviewed-on: https://gerrit.instructure.com/64473
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
since other projects have been known to upgrade npm on a jenkins node in
the course of a build, affecting subsequent canvas builds ಠ_ಠ
test plan:
npm install should be happy on npm v3
Change-Id: I6767dac7dea7c8cfb4dfabbf94a29f6cccb00c15
Reviewed-on: https://gerrit.instructure.com/63708
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
fixes: CNVS-22276
what this change does:
* changes it so if you have a 'host' set in canvs_cdn.yml,
when you run brandable_css it will push the css
files directly to s3 instead of writing them all to
disk.
* fixes the bug where brandable_css thought it had
to re-compile css files that have not changed
* changes the way we load css bundles that don't include
any branding or use any of the variant variables
(like: $use-high-contrast or $use-new-styles).
before, we generated a unique css file for each
variant and each brand for any of those bundles.
this will instead point everyone to same url if
the file uses none of those variables.
test plan:
* with no canvas_cdn.yml file:
* run compile_assets
* run it again, it should say "no changes" quickly
* the css in canvas should work
* now, rm -rf public/dist/brandable_css
* save a canvas_cdn.yml with proper s3/cloudfront settings
* compile_assets
* canvas should work and use the css that was uploaded
to s3 in previous step
* compile_assets again, it should say "no changes"
within a few seconds.
* if you can, delete a css file from s3 & run
brandable_css again. it should see that it needs
to regenerate that file and do so correctly.
when testing the css in the UI, especially make sure
to look for:
* try loading the equation editor in different variants,
(e.g.: high contrast, new styles, legacy) the css
for it should always be loaded from <cdn>/dist/brandable_css/no_variables/...
* keep your js console open, there should not be any 404s
* check the screenreader_gradebook
most of the changes actually happened in brandable_css:
https://github.com/ryankshaw/brandable_css/compare/6e0ddc59...master
when code-reviewing, please do a thorough scan of
those changes too.
Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838
Change-Id: Ie6efcedd92c3783e0b2dd194ec222b9dc28d0838
Reviewed-on: https://gerrit.instructure.com/61495
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
This also upgrades Groups to use react 0.12
so that react-tools 0.13.3 can be used.
- Upgrades react-tools to 0.13.3
refs CNVS-22335
- Converts:
- Breadcrumbs
- Breadcrumbs Collapsed Container
- Column Headers
Test Plan:
- Make sure Breadcrumbs and Column Headers work in
New Files
- Regression test Groups
Change-Id: I37ce2909223ed5fb3cf09a8e7300d286a40fe838
Reviewed-on: https://gerrit.instructure.com/60109
Reviewed-by: Dan Minkevitch <dan@instructure.com>
Tested-by: Jenkins
QA-Review: Charles Kimball <ckimball@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
fixes: CNVS-22155
see: e1b5a8e5ec?diff=unified#diff-2b4ca49d4bb0a774c4d4c1672d7aa781R23
test plan:
say the path to your canvas-lms repos is in
/Users/ryan/code/canvas-lms
make a symlink that points to that in:
/Users/ryan/current
run `brandable_css`
it should work
Change-Id: I1f732a53e56ea376efe6cd7d54b3ae52178ac025
Reviewed-on: https://gerrit.instructure.com/59342
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
the way this was written, it used to fire off
a promise for every brand all at the same time.
I’ve changed it so the memory usage will be more
like `k * <# variants>` instead of
`<# of themes> * <# variants> * k`
so it will stay constant (on my machine ~500mb) and
not grow huge as we get more people that have made
themes. (where k is the memory it takes to
compile one sass file, and # themes is a constant,
in our case 6.
Change-Id: I1fa4b4410a1141b461019f0c614ba343ea73000c
Reviewed-on: https://gerrit.instructure.com/59182
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-22056
test plan
* compile assets
* run: bundle exec rake canvas:cdn:upload_to_s3
* go to canvas in the browser, look at the network
panel, things like common.js and css files
should be transferred as gzipped (so common.js
should not be 1.4mb)
this is also a great time to test the s3/cloudfront
settings that ops set up for us in OPS-1047, instead
of using the instructure_uploads_engineering bucket
and my own cloudfront distribution that you may
have been using. go to that ticket and take note
of the settings to use for testing/dev
and put them in config/canvas_cdn.yml
Change-Id: I9c1f8d6d9128554a38cd424b6e24947d7cd92208
Reviewed-on: https://gerrit.instructure.com/58975
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
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>
closes: CNVS-21701 CNVS-21846
test plan.
* open theme editor and set just the "brand-primary" color.
* hit preview
* the background of the "global nav" on the left of
the page should be the color you set as brand-primary
Change-Id: I4781187db7543c31b71b25e414f8da6b3cda3578
Reviewed-on: https://gerrit.instructure.com/58310
Reviewed-by: Jennifer Stern <jstern@instructure.com>
Product-Review: Jennifer Stern <jstern@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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>
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>
this will allow us to enforce linting in the build
also ignore plugins' vendored javascript
Change-Id: Ibf6e9b73e0051a0b581ee52b641f9ff00dd6b2f2
Reviewed-on: https://gerrit.instructure.com/46351
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
no significant issues/vulnerabilities fixed in this commit, rather this is
a catch-all so we can enforce linting in the build.
to better understand what's going on here, see the following:
* public/javascripts/.xssignore
* script/xsslint.js
* https://github.com/jenseng/xsslint
high level summary of what's going on in this commit:
1. .html/.append/etc. now know what to do with a SafeString ... in many
cases we now put a $.raw around an .html argument to tell the linter
it's ok
2. although translation is an unlikely attack vector, we now htmlEscape
I18n.t calls used in html snippets, etc. this is a good thing, as it
ensures we don't create a vulnerability later (e.g. by interpolating
user content into a translation)
3. many vars were renamed (Html suffix, $ prefix) to let the linter know
it's something that was manually vetted
4. in some cases, rather than renaming or creating a superfluous var,
we add special xsslint comment overrides
test plan:
specs should all pass
Change-Id: Ide1df825b798d1b0c468a5308802543bf716c0d7
Reviewed-on: https://gerrit.instructure.com/46097
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Derek Hansen <dhansen@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
this swaps out our "parsing" with i18nliner-js
also remove localization abilities of I18n.beforeLabel, since it's not
worth the trouble to support. it can still be called to format a string.
notable changes/fixes in generated yml:
1. client_apps are picked up by i18n:rake so they'll get translated...
due to the old short-circuiting logic (`rc = rc && ...`), it would
stop processing scripts within a particular file after the first one
it found without an I18n.t
2. we no longer incorrectly double-escape special chars in our js strings
(e.g. newlines are actually newlines, not a literal "\n")
test plan:
1. verify string extraction:
1. `rake js:generate i18n:generate` before and after this commit
2. confirm `config/locales/generated/en.yml` is identical, except the
notable changes/fixes listed above
2. verify js translation file generation:
1. `rake i18n:generate_js` before and after this commit
2. confirm the files in public/javascripts/translations are identical
3. verify client_app checker still works:
1. `cd client_apps/canvas_quiz_statistics/`
2. `grunt check_i18n`
Change-Id: Ic8ad058bee1c9476f42916f10b612c1c08863fe3
Reviewed-on: https://gerrit.instructure.com/42809
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Product-Review: Michael Ziwisky <mziwisky@instructure.com>
QA-Review: Michael Ziwisky <mziwisky@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
the newer version we were using (0.9.5-rc1) seems to have a bug
that causes it to drop 'left' and 'right' styles
test plan:
- the 'HTML Editor' and 'Rich Content Editor' links on the wiki
page editor should appear on the right side and should not
overlap the page title
fixes CNVS-15760
Change-Id: Icab9be6b25114485f0f5d9990b1eb3c1d600b35f
Reviewed-on: https://gerrit.instructure.com/41720
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
after many steps towards this moment, we're finally here
This yanks sass and compass out of canvas-lms
completely and instead uses the libsass based
node-sass to compile our SASS files.
wins:
It is WAYYY faster!
as in, < 10 seconds to recompile all css in canvas
(compared to the 5+ minutes it used to take)
It is all in JS, helping use move to a completely
nodeJS based fronted tooling workflow.
next steps:
remove jammit: we don't need an assets.yml file
since node-sass can output compressed css for us
and we use sass to do all of our @import'ing of other
files (@colleen calls those "compiler" sheets), this
would simplify and speed up fronted asset building
even more
use gulp/broccoli/whatev to do cached, incremental builds
test plan:
all outputted css should look exactly the
same as it used to.
run `npm run compile-sass`, make sure it works
and is way faster than `rake css:generate` used to be
Change-Id: I7d865ea6b3e374cdc27a883d2019a4c15746c0e2
Reviewed-on: https://gerrit.instructure.com/38416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
Include compute-cluster in "dependencies" so `npm install --production`
works for building assets.
Test plan:
- run rm -rf node_modules && npm install --production
- run bundle exec rake canvas:compile_assets
Change-Id: Ie5b1d387608f24b59a736dbeb974cb1ec710cfbd
Reviewed-on: https://gerrit.instructure.com/34302
Reviewed-by: Jason Madsen <jmadsen@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
...by parallelizing everything I could
fixes: CNVS-12362
`time bundle exec rake canvas:compile_assets`
(on my I7 2.3GHz macbook pro)
before: "322.56s user 26.62s system 173% cpu 3:21.05 total"
after: "425.91s user 30.71s system 413% cpu 1:50.35 total"
If you ever find yourself needing to run everything all
sequentially (and not in multiple threads), you can
set the environment variable CANVAS_BUILD_CONCURRENCY=1
by default it will use all the cores your system has
You're welcome, anyone that has ever had to build canvas
or wait for jenkins to run :)
Test Plan:
* run "time bundle exec rake canvas:compile_assets"
* checkout this code
* run it again
* verify that it is faster, and everything works
Change-Id: Ib01506bc9638e86f4a329284458706279ef751ab
Reviewed-on: https://gerrit.instructure.com/33127
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
Change-Id: I26809102e68d1be5951a2eb446f2f4a0aeb40e08
Reviewed-on: https://gerrit.instructure.com/31707
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
- 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>
- first install new npm modules `npm install`
- add node_modules/.bin/ to your path or install
loom globally with `npm install -g loom` or
call the binary directly from node_modules with
`node_modules/.bin/generate <args>`
to generate objects for your ember app run
`generate <generator> <app>/<name> <options>`
examples:
generate model quizzes/user name:string
generate component inbox/modal
generate route inbox/messages/message
test plan:
- none, we aren't set up to test node code but
loom itself is well tested
Change-Id: Ibdf1d6307cbf5f2eb651d0f45aa0f94229b57814
Reviewed-on: https://gerrit.instructure.com/23387
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
"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>
Brent Burgoyne