Please fix this, I have the same problem

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.

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?

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? :-)

@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.

@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?

@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.

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

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"

@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)

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.

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)

I ended up going down the same route as @tkoenig. It seems to work well for the time being 👍

We are currently using the fork by @n-studio, but we would love to run the official version with the new features. Is anyone working on this still? We are using the new Rails 7 defaults (cssbundling-rails & jsbundling-rails).

unfortunately @n-studio's fork breaks Stimulus..
sorry, this compile-assets branch breaks Stimulus, but @n-studio's fork have fix for date-picker, so it works!
update:
I feel lost, please someone clarify.
I can't deploy app to production, because of SassC::SyntaxError: Error: Function rgb is missing argument stuff.
Branch compile-assets allows to deploy, but breaks Stimulus because of ujs\date-picker problems.
@n-studio's main branch fixes Stimulus, but I can't deploy with this fork because of SassC issues..
what should I use to be able to deploy and still have Stimulus?
Thank you.

This was quite a time consuming issue to get to the bottom of. Thanks @tkoenig and @n-studio for offering stop gap solutions.

Moving to dartsass-rails will fix this issue, i currently got it working with dartsass, i had to generate the administrate gem stylesheets in my project
here is a link to my fork with dart-sass
fork works with tailwind

Moving to dartsass-rails will fix this issue, i currently got it working with dartsass, i had to generate the administrate gem stylesheets in my project here is a link to my fork with dart-sass fork works with tailwind

i just updated the branch, now you dont need to generate the assets in your project

Neither of the forks above worked for me (because I think administrate has pushed new commits after those forks were made). So I created a new up-to-date fork here: https://github.com/materialsnow/administrate

You can run rails assets:precompile locally in the app that is leveraging Administrate to make sure that step will work during your build. Just fix any errors (like adding the assets to manifest.js) and you should be good to go.

It works for me as of this posting. I'm using Rails 7.0.4. Best of luck!

I also tried various forks and solutions mentioned on this issue page. Nothing worked. I created a fork myself https://github.com/oroth8/administrate and it works perfectly with my rails 7 tailwind configured app.

I would love it if there was official support for this.
Is there anyway we can get this merged (maybe as a major version bump)?

Actually, it looks like we managed to continue to use administrate, even with its dependency on the old sassc-rails, while the rest of our app changes to cssbundling-rails with Dart Sass (for our legacy views) and Tailwind (for new views). The key for us was to ensure config.assets.css_compressor was set to nil for all Rails environments. Without this we encountered errors such as ActionView::Template::Error: Error: Function rgb is missing argument $green and I think also errors of the type ActionView::Template::Error: Asset X was not declared to be precompiled in production. So far we haven't needed to use one of the administrate forks suggested in this PR. Also see rails/cssbundling-rails#129.

Thank you all for your solutions to this, it's been a headache! You solution @sedubois worked for me, thank you for sharing it. I just dropped Rails.application.config.assets.css_compressor = nil in config/initializers/assets.rb and it worked.

Thank you all for your solutions to this. Your solution @kaka-ruto @sedubois Thank You. I just dropped Rails.application.config.assets.css_compressor = nil in config/initializers/assets.rb and it worked.

I'm going to close this we've just merged in #2397, which will mean that in future release we'll be bundling assets in the Administrate Gem and so we've been able to drop any dependencies on assets from those using the gem.

I'm expecting this will mean Tailwind will work fine now, regardless of how you go about bundling the assets in your applications.

I'm going to start releasing some pre-release versions of the gem in the coming days, as I'm sure I'm about to break stuff for people, and so we can get feedback and make sure there's nice migration help sorted out.