Switch from sass-rails to sassc-rails #34884
Conversation
Ruby Sass will be deprecated on March 2019 so we are switching to use the SassC gem based on the LibSass C library. sassc-rails is a drop in alternative to sass-rails.
| @@ -326,7 +326,7 @@ def convert_database_option_for_jruby | |||
| def assets_gemfile_entry | |||
| return [] if options[:skip_sprockets] | |||
|
|
|||
| GemfileEntry.version("sass-rails", "~> 5.0", "Use SCSS for stylesheets") | |||
| GemfileEntry.version("sassc-rails", "~> 2.1", "Use SCSS for stylesheets") | |||
There was a problem hiding this comment.
Should we remove the upper version bound here? Like we’ve done for other dependencies.
|
Note for myself: We need to remove the sass dependency from SasscProcessor and SasscCompressor in Sprockets. |
|
What does this mean for JRuby? |
|
JRuby is supported, see sass/sassc-rails#113 |
|
After creating rails/sprockets#592, I'm wondering whether the |
|
Why change a dependency if we can change sass-rails to do what we want? Also sass-rails or sassc-rails is only necessary to add generators, so most of the code should be in sprockets. All being said I don't think we need to use sassc-rails. |
|
Yeah, adding |
Ruby sass is being deprecated; see rails/rails#34884
* Updated dashboard table titles * Migrate from sass-rails to sassc-rails Ruby sass is being deprecated; see rails/rails#34884
|
@rafaelfranca I think that ERB template support and the glob importer are the main differences between sassc-rails and sass-rails, do we want to drop them in sass-rails? or should we bring the sassc-rails implementation of those inside of sass-rails? |
|
Ok, my plan to move this forward is this:
I don't think we should continue maintaining/releasing new versions of sass-rails when sassc/sassc-rails are well maintained under Sass organization and are very popular among many apps. |
|
We still need the generators, how are you planning to address it? I don't think it is good to give control of one of our default gems to sass organization. I'd prefer to make sass-rails just a wrapper around sassc with generators support. |
|
I'm fine with keeping sass-rails if we don't need to copy over all the code to support glob imports and erb support from sassc-rails (in that case we will be just making a clone of sassc-rails). |
|
ERB support seems very important, to me... glob imports I'd prefer to keep but could imagine sacrificing for good reason. ISTM the smoothest compatibility bridge would be to turn sass-rails into a thin wrapper of sassc-rails -- that way anyone who upgrades their existing Gemfile will get the modern tooling. And moreso than who controls it, it keeps our Gemfile focused on the functionality it wants ("sass [language] integration for rails") over the technology that provides it (sassc). |
|
@matthewd thanks, I will do exactly that! |
|
Done in rails/sass-rails#424, so I'm closing this! |
Ruby Sass will be deprecated on March 2019 so we are switching to use the SassC gem based on the LibSass C library.
sassc-rails is a drop in alternative to sass-rails.
This closes #32896