sassc dependency breaks compatibility with tailwindcss-rails

[philipithomas]

• What were you trying to do?

I'm trying to use tailwind-rails v2.0.2 and importmaps.

• What did you end up with (logs, or, even better, example apps are great!)?

I'm getting a SassC::SyntaxError when I run rake assets:precompile. Based on my debugging, it's because tailwind-rails is incompatible with the sassc-rails gem that administrate requires as a dependency:

Tailwind uses modern CSS features that are not recognized by the sassc-rails extension that was included by default in the Gemfile for Rails 6. In order to avoid any errors like SassC::SyntaxError, you must remove that gem from your Gemfile.

• What versions are you running?

Rails 7.0
Administrate 0.16.0

[AnalyzePlatypus]

Please fix this, I have the same problem

[n-studio]

The solution is pretty simple: we need to get rid of all JS/CSS dependencies and just mention how to add them in the README.

We must let developers choose the way they handle their assets, whether it's using sassc, webpack or importmap.

Maybe we can add some generator rails g administrate js:importmap or something like that.

[etozzato]

administrate is a Rails::Engine, which means it is a Rails app. Would it be useful to refactor the code following the 'update to rails 7 guides' and homogenize the handling of resources?

[pablobm]

Unfortunately, this may not be simple at all. Before Rails 7, there were two main ways of handling assets: Webpacker and Sprockets. We have tried to make Administrate work with both, but it's difficult work and complex to reproduce issues.

Now Rails 7 has arrived with yet another way to do things. We'll have to spend the time to make it work there too, and we would rather that Administrate kept working with previous versions of Rails (at the moment we support Rails 5+).

I haven't used Rails 7 yet and I haven't really read much about how the new way to work with assets is. I will have to eventually, but right now I'm a bit short of time so I don't know when I'll get to sit down and figure this out :-/

Fortunately, it doesn't need to be us maintainers who do this work. One of you may be able to volunteer and offer a first stab at the solution. It doesn't need to be a complete PR: an initial prototype could help communicate what exactly needs to happen, and to start testing if there are issues with back compatibility.

Any takers? :-)

[n-studio]

@pablobm
I have a fork compatible with Rails 7, I'll try to make it retrocompatible and submit a PR this weekend.
Are you ok with the idea of adding generators to add assets in the Rails app? This would be a breaking change but the upgrade would be easy and straightforward.

[n-studio]

@pablobm Another way to fix this issue is to compile the assets and commit the compiled assets. This would avoid breaking changes. Would you prefer this method?

[pablobm]

@n-studio - I would consider it. If you create a PR so that I can see what it looks like, it can help me understand.

[n-studio]

@pablobm Here is my PR #2116
I hope you like that solution.

[dvruette]

I've been running into the same issue and the PR by @n-studio seems to fix it, thank you so much!

As a hotfix for anyone else running into this, I've added the branch with the fix to the Gemfile like so:

gem "administrate", github: "n-studio/administrate", branch: "compile-assets"

[philipithomas]

@dvruette

I've been running into the same issue and the PR by @n-studio seems to fix it, thank you so much!

As a hotfix for anyone else running into this, I've added the branch with the fix to the Gemfile like so:

gem "administrate", github: "n-studio/administrate", branch: "compile-assets"

This is a completely valid fix - but it will break if @n-studio deletes that particular branch in the future. And, it's a development branch - not main - so it's not reasonable to expect it to stick around. So, please fork the code to your own Github if you want to follow this approach! (and replace github: "n-studio/administrate" with your own fork)

[tkoenig]

What I did for some projects which still depend on Sass was creating my own compressor, which skips the SassC compression if it fails.

class SkippingSassCompressor
  def compress(string)
    options = { syntax: :scss, cache: false, read_cache: false, style: :compressed}
    begin
      Sprockets::Autoload::SassC::Engine.new(string, options).render
    rescue => e
      puts "Could not compress '#{string[0..65]}'...: #{e.message}, skipping compression"
      string
    end
  end
end

Since the skipped (tailwind) files, are not compressed this way, I just added the --minify option to the tailwindcssCLI to compress them as well.

"build:css": "tailwindcss -i ./app/assets/stylesheets/home.tailwind.css -o ./app/assets/builds/home.css --minify"

I did not test this especially with administrate, but have this working on multiple projects where we want to slowly migrate to tailwind.

[januszm]

Would this help here? sass/sassc-ruby#220 (comment) / https://github.com/ntkme/sassc-embedded-shim-ruby
(but ultimately yes, removing sass from this project is another option)