test plan:
with guard running:
edit a handlebars file that has a corresponding
sass file.
e.g.: app/views/jst/FolderTreeItem.handlebars
it should not crash guard
Change-Id: Icd04510dc4ac0ff80674d1b3116da0dccb199fd9
Reviewed-on: https://gerrit.instructure.com/41019
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-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. put some invalid sass in a jst stylesheet
2. you should see the error in the guard output, but guard shouldn't die
Change-Id: Idd07ba3c64f89d35e79e3f6a886a28a26f8e8a1c
Reviewed-on: https://gerrit.instructure.com/24557
Reviewed-by: Mark Ericksen <marke@instructure.com>
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@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>
Ryan Shaw