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>