search

rails / sass-rails

Ruby on Rails stylesheet engine for Sass
MIT License
859 stars 333 forks source link

Make sass-rails an wrapper for sassc-rails to allow a smooth upgrade #424

Closed guilleiguaran closed 5 years ago

guilleiguaran commented 5 years ago

This closes https://github.com/rails/rails/issues/32896 and https://github.com/rails/sass-rails/issues/420

guilleiguaran commented 5 years ago

If there aren't any objections before of the weekend I will merge this and release a new beta version of sass-rails.

kaspth commented 5 years ago

Fine by me 🙏

DeeDeeG commented 5 years ago

As just a typical user of Rails, I think this provides a super easy transition to sassc. I'm also glad it will (I hope) help lots of other people do the same. I'm all for it. Thanks for this PR! :+1:

jeffnyman commented 5 years ago

I apologize for my ignorance here but as someone relatively new to Rails projects, I'm curious as to what the course of action should be. I have the following line in my Gemfile (using a project set up on Rails 5.2.2.1):

gem 'sass-rails', '~> 5.0'

I get the post install message from the sass gem regarding the deprecation.

Does this wrapper mean that I don't need to change the above line to this:

gem 'sassc-rails'

Or should I still make that change anyway?

guilleiguaran commented 5 years ago

@jeffnyman hey!

This will be released as 6.0 so in your case you will need to remove the version restriction on the Gemfile if you want to get the next version of sass-rails.

You can change the dependency manually to sassc-rails if you want to get SassC right now (since this will be released first as Beta), this PR will just make to sass-rails an "alias" for sassc-rails so everyone using sass-rails or sassc-rails will be using SassC in the future.

DeeDeeG commented 5 years ago

I browsed the files of this repository, as changed with this pull request, to see what is still left: https://github.com/rails/sass-rails/tree/706526d411d2d78e578c7944e873ece28e65ed42

It doesn't appear to do very much anymore other than:

Meanwhile, sassc-rails is already designed to be a drop-in replacement for (the non-wrapperized version of) this gem, sass-rails.

I myself am not an expert, so I may have missed something or misunderstood the details.

guilleiguaran commented 5 years ago

@DeeDeeG that's right, we just want to move automatically to folks using this lib to use sassc instead of raising an warning saying that this is deprecated and that they should move manually.

DeeDeeG commented 5 years ago

And I think sassc-rails loads sassc on the Rails server as well. Should the lib folder of this repo be removed in this PR? Or to satisfy my curiosity: Can I ask what the files in the lib folder do that is better than deleting it? (Would something likely break?)

Thanks for being available to discuss and answer questions @guilleiguaran

guilleiguaran commented 5 years ago

@DeeDeeG

I'm keeping the files for the folks that are requiring them directly, e.g:

require "sass/rails/importer"

Instead of raising an error in that case we are requiring the corresponding file in sassc-rails, in this case sassc/rails/importer

unicornrainbow commented 3 years ago

Sorry, I don't agree. Sass-rails should handle integration of sass into rails.

If that means the sass gem, then it need not to be concerned with the sassc integration or gem, and if some EOL dictum is to be accepted being handed down from on high, then it should be EOL'd too.

If sass means SASS! Then it should try to handle the multiple Sass engines that exists and are desired to be used. Even perhaps ones that may be "EOL", tra la la. But there are at least 3, and LibSass says it is deprecated now, and is directing readme reader's to use Dart Sass. It's a wild goose chase, and honestly can be very easily solved by allowing the user to pick their engine, having the Rails integration code centralized in a single place, perhaps most appropriately this repository (strange it would be to load the ruby sass gem or Dart sass from the sassc-rails gem, no?).

Side note: Talk of EOL and deprecation is a bit silly because nobody is really asking for much, it works, and if people want to make it better, they should feel free to do so. It's opensource.

So, things as they are, this is essentially a dead project. But rather it could be a very beneficial project if it would outright handle the integration across multiple Sass engines into Rails.

To do this, it shouldn't have a dependency on any of the engines. The user can add the engine they want by adding its Gem, which Sass-Rails could sniff out and then configure automatically.

If multiple engines are loaded, then there could be a preference order imposed, and the user should also have the means to explicitly specify the Gem/engine to use.

Leaving it there, here's a 🥪.

Good luck and gravitas!