just check in main.coffee, it pretty much never changes (especially since
the ember srgb will diaf soon)
this is (hopefully) one of the last pieces of the webpack puzzle
test plan:
* webpack and requirejs builds should be happy
* srgb should boot up in both
Change-Id: Icc1a6ad811cffca5ef18a6858d9103c9bbccf037
Reviewed-on: https://gerrit.instructure.com/103352
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
this also upgrades our custom guard plugins to watch the correct
directories for plugins files. they were never updated after plugins
moved from vendor/plugins to gems/plugins.
Note: there is a small inconsistency between the latest guard and latest
thor gems resulting in a warning being printed on guard startup:
"Expected string default value for '--listen-on'; got false (boolean)"
I have a pull request open to fix this here:
https://github.com/guard/guard/pull/862
refs CNVS-34084
test plan:
- run guard
- change files
- guard should do the right thing
Change-Id: Iffc0297a458f6261130e12c151d37ecbc38ee0ec
Reviewed-on: https://gerrit.instructure.com/98657
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
this will do a check to make sure all the node_modules
from our package.json are up-to-date before
running rake canvas:compile_assets or guard
there have been a lot of devs lately that have
been tripped up not knowing what to do because
they needed to `npm install`
Change-Id: I7c9d0896a6d7611bf9d89672a96cb9505099fa2c
Reviewed-on: https://gerrit.instructure.com/58580
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
I think the problem that we were getting was because
we added guard-gulp to our development gemfile
and it maybe require's mkmf, which adds the
.with_config scope.
test plan:
* go to conversations in dev mode, it should work
* run `bundle exec guard`, it should work
* with guard running, change a coffee/js file
* guard should see the change and regenerate the appropriate file
and you should see gulp 'rev' run.
Change-Id: Ia43e9436e19b32eb3959f6f2d9c2d8d7674aa109
Reviewed-on: https://gerrit.instructure.com/57777
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@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>
fixes CNVS-11426
The UI/UX team *really* wants to start doing some major style changes
to the canvas interface. Because it is a very visual change and especially
because we've let people hack the crap out of canvas styles with
their own css override file, any changes we do need to be behind a
feature flag so an institution can opt-in when they are ready.
This commit does some trickery so we actually create 4 different versions
of every stylesheet. one for each variant in:
legacy_normal_contrast legacy_high_contrast
new_styles_normal_contrast new_styles_high_contrast
and then sets the $use_new_styles and $use_high_contrast sass variables
accordingly in each.
now, in any sass file, you can do things like:
@if $use_new_styles {
background-color: red;
} @else {
background-color: blue;
}
@if not $use_high_contrast{
font-size: 12px;
}
test plan:
* in a production (minified assets) environment, ensure you see:
<link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page
* go to the account settings page for the domain_root_account you are on
* turn on the "Use New Styles" feature
* now verify that <link href="/assets/common_new_styles_normal_contrast.css...
is in the <head>. There should not be any visible differences because we do
not have any styles that target specifically $use_new_styles yet.
* now, go to /settings and turn on the user feature for "Use High Contrast Styles"
* verify that <link href="/assets/common_new_styles_high_contrast.css..
is in the <head>
* again, turning that on will not actually change the way anything looks,
the next commit (g/32863) will take care of that
Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418
Reviewed-on: https://gerrit.instructure.com/31881
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>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
1. guard should Do The Right Thing™
Change-Id: Ic77d28d2a7ebfc3f1185ffdc7608b800d9a85dab
Reviewed-on: https://gerrit.instructure.com/25973
Reviewed-by: Cameron Matheson <cameron@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
now when you update or delete a jst s[ac]ss file:
1. guard recompiles (or deletes) the css (don't need to wait for compass
middleware)
2. guard recompiles the corresponding .handlebars so that it has the
correct embedded css
test plan:
it should no longer be ridiculously painful to use jst css files. in other
words, change your file, refresh the page, voila!
Change-Id: I61e245dc827fd5006cc7cd0af4e074bb8c5108cc
Reviewed-on: https://gerrit.instructure.com/24459
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This commit adds ember.js (http://emberjs.com)
libraries to canvas.
Ember apps can be created by
adding a directory to 'app/coffeescripts/ember',
e.g. 'app/coffeescripts/ember/inbox/'
Shared Code
-----------
'app/coffeescripts/ember/shared', contains shared
resources between ember apps.
'shared/helpers/common' is included in all ember
templates.
Tooling
-------
- Bundles will be auto-generated by file system
naming conventions, see lib/ember_bundle and its
specs for details.
- Guard will precompile templates and create the
bundle file when files are changed
- Rake tasks added for deployment `jet:ember` and
`js:bundle_ember_apps`
Change-Id: I6d4177891cb618d5dbff3c87553fbf448e91393b
Reviewed-on: https://gerrit.instructure.com/22688
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
also remove the need for Guardfile within plugins (and stop including
them)
note that guard still can't detect changes to files in symlinked plugins
on the mac (due to fsevent), though you can hit enter to recompile everything
test plan:
1. clone a plugin into vendor/plugins
2. start up guard
3. edit a coffee file in the plugin
4. guard should detect it and compile it in the right place
5. edit a coffee spec file in the plugin
6. guard should detect it and compile it in the right place
7. edit a handlebars file in the plugin
8. guard should detect it and compile it in the right place
9. hit enter
10. guard should compile all coffee/handlebars files in the right place
Change-Id: I1e7c12f1368af66dee024e258899412526bb3fd2
Reviewed-on: https://gerrit.instructure.com/20219
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
given app/coffeescripts/foo.coffee in canvas-lms, if you want to monkey
patch it from your plugin, create app/coffeescripts/extensions/foo.coffee
(in your plugin) like so:
define ->
(Foo) ->
Foo::zomg = -> "i added this method"
Foo
and that's it, no changes required in canvas-lms, no plugin bundles, etc.
note that Foo is not an explicit dependency, it magically figures it out.
also note that your module should return a function that returns Foo.
this function will magically wrap around Foo so you can do stuff to it
anytime somebody requires "foo" as per usual.
test plan:
1. use it as explained above
2. it should work
Change-Id: If3b21782c0e79bb0ce55b4f16804047a2c2e2143
Reviewed-on: https://gerrit.instructure.com/20004
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
1. start guard
2. save a file in app/stylesheets
- styleguide should be created (guard will
tell you)
3. hit enter
- styleguide should be created
Change-Id: I891a906602b6df0f964f2e502f124f5d05b4b796
Reviewed-on: https://gerrit.instructure.com/19525
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
also added styles to make .form-controls look
good in dialogs.
closes #CNVS-4302
Change-Id: Ibe54ee4046ac255b0b0ea83d32afc88e4a820464
Reviewed-on: https://gerrit.instructure.com/19331
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
The load path no longer includes the current directory (".") in 1.9, so
guard couldn't find some of its scripts.
Change-Id: Ib254934d41c0972381eee87062ae9ef57fd5c12c
Reviewed-on: https://gerrit.instructure.com/14877
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
test plan:
* checkout patchset 1 from https://gerrit.instructure.com/7469
* symlink the canvalytics repo into vendor/plugins/
* symlink public/plugins/canvalytics to vendor/plugins/canvalytics/public/
* run guard, regenerate all files
* make sure the route /analytics/course/<id>/user/<id> renders handlebars
unit tests not provided for this scaffolding stuff
Change-Id: Ibf626555cbb79a5a97d67286ef4a7d8f28f53de8
Reviewed-on: https://gerrit.instructure.com/7470
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
couldn't actually get the run_on_deletion method working
but if you start guard and hit enter in that terminal window
it will delete the entire public/javascripts/jst directory
and re compile all
Change-Id: I25df0bc2cc0031c61e32c0141cef7d3f688a1056
Reviewed-on: https://gerrit.instructure.com/6171
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
now we can have things like
app/coffeescripts/lib/myWidget.cofffee
(also changed to regex watch pattern to get rid
of deprecation warning)
Change-Id: Ia6561dcb57215b2b1b405bcd64c43d7fd2ded85d
Reviewed-on: https://gerrit.instructure.com/5894
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
- New rake task `rake jst:compile` to precompile
JavaScript templates into functions.
Add handlebars templates to app/views/jst and
they'll get compiled to public/javascripts/jst
- New rake task `rake jasmine` and `jasmine:ci` to
run JavaScript specs.
Add specs to spec/coffeescripts and they'll get
compiled into spec/javascripts
- Added Guard gem `$ guard` that watches
coffeescript and handlebars files and compiles
them when changes are made.
- Created Handlebars Ruby class that precompiles
the templates into JavaScript functions
- Added JS Template constructor to abstract
our tempting API
Change-Id: Ie993d0fc50d49b161ed94dbc066c4475cefdc427
Reviewed-on: https://gerrit.instructure.com/5813
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>