Closed johanhalse closed 2 years ago
Dealing with the evolution of asset handling in Rails has definitely been one of the biggest challenges (and energy drains) in developing Trestle and it's something that continually plays on my mind as to how it should work in future releases, especially with the multitude of new asset compilation options available now or in the near future.
To give you and idea of how it currently works, the CSS (and JS) in Trestle currently is split into two -- the core bundle and the theme. The core bundle today is shipped precompiled and minified -- see bundle.css -- using a process that is conceptually pretty similar to cssbundling-rails but with a custom webpack build step.
Whilst Trestle currently has a dependency on sprockets-rails
, this approach should also work fine with Propshaft, although I haven't dived into that yet. There may be some complications as I also use .erb
assets to ensure only the relevant i18n asset files are loaded.
The theme files are where the SCSS comes into play. This load path is only added when Trestle.config.theme
is enabled, which by default is if a Sass
or SassC
constant is present. On a new Rails 7 app, you'll probably find this not to be the case. Confusingly, the error you see is coming from the app/assets/trestle/_*.scss
partials created by the trestle:install
generator, and deleting those files (also run rails tmp:cache:clear
) should resolve it, albeit without any custom theming.
So where to going forward? I've been busy working in a private branch on a major rewrite of the front-end JS & CSS, which includes Turbo/Stimulus, Bootstrap 5.1, etc. I'm finishing up some private testing very soon so will publish the branch for public testing once I have the major remaining issues resolved.
For theming, it's probably worth looking at a pure HTML variable theming option. I'd deferred this previously due to browser support but Bootstrap 5 drops support for older browsers (IE11) anyway so it's certainly time and hopefully achievable with effectively the same feature set.
With this release, it'll also be time to drop sprockets-rails
as a hard dependency although I will need to make sure it can work in all configurations without Sprockets (e.g. Webpacker only). I also want to explore the ability to create a fully custom admin bundle by importing only the desired JS/CSS files from a Trestle NPM package.
Thank you! That's great to know - my app is greenfield Rails 7 and I'd love to lose my Sprockets/SASS dependencies. With the frontend part of Rails in so much flux right now it's pretty hard to see where things are going, though.
Any news with the new rails' way of handling the front-end?
I would be interested about this too!
Hey, @spohlenz! Any news with this issue? How can we help you?
~/Code/mhenrixon/cosmos · (feat/invoicing ±)
➜ rails generate trestle:install 03/12/24 - 9:50 AM
[dotenv] Loaded .env
/Users/mhenrixon/.gem/ruby/3.3.0/gems/sprockets-rails-3.4.2/lib/sprockets/railtie.rb:110:in `block in <class:Railtie>': Expected to find a manifest file in `app/assets/config/manifest.js` (Sprockets::Railtie::ManifestNeededError)
But did not, please create this file and use it to link any assets that need
to be rendered by your app:
Example:
//= link_tree ../images
//= link_directory ../javascripts .js
//= link_directory ../stylesheets .css
and restart your server
For more information see: https://github.com/rails/sprockets/blob/070fc01947c111d35bb4c836e9bb71962a8e0595/UPGRADING.md#manifestjs
These last years have seen the Rails frontend lose a lot of its uniformity. We can't depend on Sprockets being available anymore, and it's being replaced by Propshaft. Sass isn't there by default, and while you can install it with some command-line switches, the
sassc
compiler conflicts with the popular Tailwind gem: https://github.com/rails/tailwindcss-rails#conflict-with-sassc-rails. If you create a new Rails app using defaults and then install trestle, you'll get hit withLoadError (cannot load such file -- sassc)
.So it would be nice if Trestle just shipped standard CSS! I've had a look at the scss files, and untangling all the nesting and variables etc will be big and messy. Perhaps there could be some sort of build step before every release, and the admin could use that pre-built CSS? I haven't looked into the details (like asset references or including custom user CSS) but I think moving away from a hard dependency on Sprockets and sassc will be beneficial to the project.