Deprecation plans

[stof]

Now that libsass is deprecated, what are the plans for this project ? Should it be marked as deprecated as well ?

[januszm]

Is there any existing or potential replacement for this gem for Rails, apart from changing things completely and compiling css with Webpack using Dart-Sass? Currently there seems to be a problem with a long compile time (approx. 2 minutes) and this has been going on for almost 2 years. There are suggestions for solutions like amalgamate or shipping precompiled , but from what I can see they are not merged and updated for a long time. https://github.com/sass/sassc-ruby/issues/132 https://github.com/sass/libsass/pull/2979 https://github.com/sass/sassc-rails/issues/152 https://github.com/sass/sassc-rails/issues/151 https://github.com/sass/sassc-ruby/issues/189#issuecomment-758327172

[cyclotron3k]

libsass is deprecated and all development efforts were focused onto Dart Sass which is still alive and well. I just noticed that Dart programs can be compiled to native executables. Perhaps sassc-ruby can be distributed with precompiled Dart Sassc binaries? (In the same way that wkhtmltopdf-binary is distributed with precompiled binaries?)

[stof]

@cyclotron3k sassc-ruby does not use the sassc executable. It uses the libsass C library through FFI.

The replacement will more likely be dart-sass-embedded, for which a Ruby host is in progress at https://github.com/ntkme/sass-embedded-host-ruby

[javierav]

@stof any idea on how use this gem in the assets pipeline?

[ntkme]

New apps are recommended to migrate to sass-embedded.

For existing apps you can use sassc-embedded as a drop in replacement for sassc.

See https://github.com/ntkme/sassc-embedded-shim-ruby for details.

[jacob-carlborg-apoex]

I think https://github.com/rails/dartsass-rails is the official replacement from Rails' point of view.

[ntkme]

I think https://github.com/rails/dartsass-rails is the official replacement from Rails' point of view.

The rails team is moving away from sprockets. Doing so comes with the cost of missing features, such as custom sass functions in Ruby that many existing projects rely on. The purpose of the shim is to help existing projects to migrate.

Update: dartsass-rails now uses the dart-sass binary provided by sass-embedded gem so it's always up to update.

[johnnyshields]

I've have made PR #240 which merges @ntkme 's dart-sass shim code into this repo. That PR branch is now being used successfully at TableCheck and Discourse.

I'd like to propose to nominate new maintainers for this gem so that we can continue to support it. I'm willing to be an interim maintainer if no one else is available.

[xfalcox]

@johnnyshields do you plan to keep updating your current dart-sass branch? I'd convert it to a full fork, with open issues, and merge it to your main branch and start telling people to use it.

[johnnyshields]

OK I'll handle that today. Thanks!

[johnnyshields]

dartsass-ruby gem is released! 🎉

[johnnyshields]

Looks like we also need to fork sassc-rails. I'll get on that now.

[ntkme]

Here is my comment from a different but similar issue regarding the effort of replace sassc completely with my shim:

TL;DR: If you care about the experience, please directly integrate with sass-embedded or ask the dependency you use to do so. I would encourage the community to contribute such integration in other projects.

The main problem is that many apps have sassc as dependency in gemspec and require 'sassc' in dependency code that they don't have any control over. This means you really have to fork every single project using sassc just to replace the sassc dependency in gemspec. The original shim solves this problem by simply install a fork of sassc from git and then require 'sassc-embedded' from it to complete the redirection so that you don't have to fork other packages depends on sassc and just to modify the gemspec.

There are quite a few other issues. Dart Sass made the decision to revamp the importer behavior and which is very different from sassc. In Dart Sass, an @import or @use directive will strictly map to only one file, whereas in sassc, it used to be possible use glob like @import 'modules/*' to import multiple files. In order to support this, sassc-embedded uses a custom importer that generates an intermediate stylesheet to import all the files resolved from a glob pattern. This is not only discouraged as it defeats the purpose of the new module system (@use), and will be broken once Sass drops support of @import in the future. There are a few more things made more strict in Dart Sass that sassc-embedded has they loosen to be compatible with sassc, for example, to allow importing files without extension name, which can be a security issue depends on system configuration. Other than importers, there's the issue with custom functions in sassc that functions are registered as globals rather than locals, leading to thread safety problems like https://github.com/rails/sprockets/pull/759, and eventually affect performance even after the fix. Not to mention no way to access keyword arguments and other new features not being supported (not possible without breaking existing code).

My take is that sassc-embedded is nothing but a stopgap solution to buy some time and let users in the ruby ecosystem migrate their Sass/Scss code to the latest Sass implementation with minimum effort.

The shim is not meant to be the long term solution, as the sass-embedded gem with the new Ruby API closely mirroring the new JS API from upstream is the future.

While it is nice to everyone else that you want to maintain an obsolete technology, promoting it as a permanent solution is just a step backward.

[johnnyshields]

@ntkme

Please directly integrate with sass-embedded or ask the dependency you use to do so.

Yep, that's exactly what the new dartsass-ruby gem does.

There are quite a few other issues.

It would be good document the known issues and put it in the gem's README. Users should be aware.

While it is nice to everyone else that you want to maintain an obsolete technology, promoting it as a permanent solution is just a step backward.

From my perspective:

1. There needs to be a gem that provides Sass integration with Rails asset pipeline (Sprockets).
2. The rails/dartsass-rails gem is not a good solution, as it requires running external processes. It feels like a step backward from what sassc-rails did.
3. Re: the gems I've released, the only thing "permanent" is the gem's interface with Rails. The internals of the gem can be refactored if/when new Sass APIs become available.

It would be great if you could join as a co-maintainer, or I can transfer full ownership to you if you prefer. I just want a released gem that we can use today and improve in the future.

(To be clear: I don't actually want to maintain these gems, I would much prefer if someone else did it!)

[ntkme]

Yep, that's exactly what the new dartsass-ruby gem does.

What I meant is to completely rewrite sprockets sass integration to directly use sass-embedded. There will be a few breaking changes in terms of features, but otherwise when Dart Sass 2.0 is released the shim will no longer work and it will actually be impossible to shim at that point due to already planned breaking changed. This is nothing but buy you time before that happens.

[johnnyshields]

OK, noted. Hopefully someone can refactor dartsass-sprockets when that time comes and release it as a new major version.

Are the new APIs ready in sass-embedded today?

[ntkme]

@johnnyshields See the documentation https://rubydoc.info/gems/sass-embedded/Sass, this Ruby API is an exact mirror of the official new JS API.

[johnnyshields]

OK I understand now. Your shim adds support for SassC features that were intentionally dropped or made more strict in Dart Sass. So users will have no choice but to upgrade their SCSS files.

I will work to sunset the shim code and make it so that dartsass-sprockets connects directly to sass-embedded with as little adapter code as possible.