ylqjgm
/
canvas-lms
mirror of https://github.com/instructure/canvas-lms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
canvas-lms/Gemfile.d/assets.rb

14 lines
347 B
Ruby
Raw Normal View History

partition Gemfile this is a proof-of-concept to see if partitioning our Gemfile helps more than it hurts. It's modeled after the way the Squash team handles its dependencies this doesn't implement any of the particularly nice things that can be found in the Squash set up, such as conditionally loading gems based on the contents of our configuration files (we can already sort of do this with groups in bundler), but it's a start. In particular, it allows us to add non-OSS gems to Gemfile.d without necessarily having to release it as part of our open-source packaging Change-Id: If7ff1fe97409de4cd09867ad5be1c4134c5d0117 Reviewed-on: https://gerrit.instructure.com/32442 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Nick Cloward <ncloward@instructure.com> Product-Review: Anthus Williams <awilliams@instructure.com> QA-Review: Anthus Williams <awilliams@instructure.com>
2014-03-27 06:41:23 +08:00
group :assets do
use autoprefixer to +,- css rules to match the browsers we support AKA: run all of our compiled sass through autoprefixer so we don't serve css designed for browsers we don't support and so that we do output css for the browsers we do support. This will result in us sending the browser A LOT less css. see this patch for how much it will remove from our current css: https://gist.github.com/ryankshaw/fd0ea0a8af4596569dcb The idea going forward would be to write your css prefix-free and just let autoprefixer handle the rest for you. Also, now that this exists, we could (and should) retroactively go through the code base and remove some of these places where we have these prefixes to keep our css more maintainable. test plan: open /styleguide (or any canvas page) in ie10 (or any browser) it should look exactly the same as it did before Change-Id: I7e55518d69580af692a8f04ac6fe2b491f7678af Reviewed-on: https://gerrit.instructure.com/34940 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Colleen Palmer <cpalmer@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com>
2014-05-15 07:37:40 +08:00
gem 'autoprefixer-rails', '1.1.20140512'
a way for accounts to opt-in to new styles and users to high-contrast 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>
2014-04-03 14:37:18 +08:00
gem 'compass', '0.12.4'
gem 'chunky_png', '1.3.0'
gem 'fssm', '0.2.10'
gem 'sass', '3.2.18'
partition Gemfile this is a proof-of-concept to see if partitioning our Gemfile helps more than it hurts. It's modeled after the way the Squash team handles its dependencies this doesn't implement any of the particularly nice things that can be found in the Squash set up, such as conditionally loading gems based on the contents of our configuration files (we can already sort of do this with groups in bundler), but it's a start. In particular, it allows us to add non-OSS gems to Gemfile.d without necessarily having to release it as part of our open-source packaging Change-Id: If7ff1fe97409de4cd09867ad5be1c4134c5d0117 Reviewed-on: https://gerrit.instructure.com/32442 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Nick Cloward <ncloward@instructure.com> Product-Review: Anthus Williams <awilliams@instructure.com> QA-Review: Anthus Williams <awilliams@instructure.com>
2014-03-27 06:41:23 +08:00
gem 'dress_code', '1.0.2'
re-add indentation semantics to Gemfile during a previous commit (SHA 10e7b5b003bea9aea3286b9170f5e04b8a9e3735) we removed indentation of gems, but this indentation had semantic significance for us: any gem which was not required by canvas but was required by another gem required by canvas was indented. This allowed us to clarify that canvas didn't actually use the gems while still locking into specific versions of each Also added a comment explaining this to Gemfile Change-Id: I0f476e1bed6156f2f5969e54d56d44ded5442a0f Reviewed-on: https://gerrit.instructure.com/32588 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Simon Williams <simon@instructure.com> Product-Review: Anthus Williams <awilliams@instructure.com> QA-Review: Anthus Williams <awilliams@instructure.com>
2014-04-01 00:35:44 +08:00
gem 'colored', '1.2'
gem 'mustache', '0.99.5'
gem 'pygments.rb', '0.5.4'
gem 'posix-spawn', '0.3.8'
gem 'yajl-ruby', '1.1.0'
partition Gemfile this is a proof-of-concept to see if partitioning our Gemfile helps more than it hurts. It's modeled after the way the Squash team handles its dependencies this doesn't implement any of the particularly nice things that can be found in the Squash set up, such as conditionally loading gems based on the contents of our configuration files (we can already sort of do this with groups in bundler), but it's a start. In particular, it allows us to add non-OSS gems to Gemfile.d without necessarily having to release it as part of our open-source packaging Change-Id: If7ff1fe97409de4cd09867ad5be1c4134c5d0117 Reviewed-on: https://gerrit.instructure.com/32442 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Nick Cloward <ncloward@instructure.com> Product-Review: Anthus Williams <awilliams@instructure.com> QA-Review: Anthus Williams <awilliams@instructure.com>
2014-03-27 06:41:23 +08:00
end