basecamp
undefined method `assets' for #<Rails::Application::Configuration
As we're not using # require "sprockets/railtie" - I've encountered a problem with audits1984 engine:
undefined method 'assets' for #<Rails::Application::Configuration
I fixed it locally by conditional statement
initializer "audits1984.assets.precompile" do |app|
if app.config.respond_to?(:assets)
app.config.assets.precompile << "audits1984_manifest.js"
end
end
Would that be a problem to merge it into code base 🥺 ? Cheers!
Hey @AlicjaCyganiewicz I'm hitting the same error. May I ask where you did add this conditional? Did you use a fork of the gem?
@nicalpi I had the same issue and had to fork the gem with that conditional. And then added the following initializer to fix the styling of the UI.
# config/initializers/audits1984.rb
unless Rails.application.config.respond_to?(:assets)
gem_asset_root = Audits1984::Engine.root.join("app/assets")
tmp_asset_root = Rails.root.join("tmp/audits1984/assets")
# Create audits1984 css and js files
asset_files = [
"javascripts/audits1984/application.js",
"stylesheets/audits1984/bulma.min.css",
"stylesheets/audits1984/application.css",
]
asset_files.each do |file|
unless (local_file = tmp_asset_root.join(file)).exist?
local_file.dirname.mkpath
local_file.write gem_asset_root.join(File.dirname(file)).children.map(&:read).join("\n\n")
end
end
# Serve custom assets instead of audits1984's (that will 404 without the asset pipeline)
Rails.application.config.middleware.use Rack::Static,
urls: %w[/javascripts/audits1984 /stylesheets/audits1984 /images/audits1984],
root: tmp_asset_root
end
Nice, thanks a lot @coalest. I ended up doing something similar in the end, so it's good to know I'm not the only one with the same issue.
We've had to do the same, definitely feels like something that should be fixed without forking
Sorry, I'm reopening this one as the patch I had merged wasn't really feasible as a generic solution for the gem.
If you're not using propshaft/sprockets, what are you using? I'd be willing to add support for import maps such as we do in Mission Control jobs (see this and this). Is someone willing to work on that?
@jorgemanrubia Our asset pipeline is outsourced to a CDN, packaged along with our Vue frontend. For serving other assets, like the Sidekiq Web UI, we serve it directly through Rack, similar to how the PR above does it.
I'm also open to having an API-only mode, where there is no UI.
On our end, we're using vite_rails in that app.
Isn't it risky to end up having tons of additional implementations in the audits1984 repo, for a bunch of different ways to serve assets? Maybe just exposing some hooks or something would be the way to go?
@rosa just addressed this same problem for Mission control jobs. I'd like to use the same approach here. I'll try to get to this but I have other things in my queue, so I'd appreciate a PR if someone feels like working on this.
I'll have a look, @jorgemanrubia! 🙏 Also, @jipiboily, I realised I forgot about vite_rails in that other PR. I need to look into how that one works, as I'm not familiar with it, and see how the solution could be expanded to support it.
@jipiboily, I spent some time looking into vite_rails and testing this and it seems you can use propshaft together with that without any issues, so I think I'm going to pursue the same approach here as for Mission Control, like @jorgemanrubia suggested!
@AlicjaCyganiewicz @nicalpi @coalest @humzahkiani-JW @jipiboily, if you want to give a try at #61 please do! I hope it fixes your issues. Basically, just add propshaft to your app with that branch.
@rosa it appears to work with propshaft for the most part! The only issue I am seeing is the CSS styling missing in the UI.
Ohh, unfortunately that means it's not quite working as it should, as the CSS are one of the things that should be working fine thanks to importmaps and propshaft. Could you check the request to fetch the CSS in your network tab and find the corresponding request in your local server to see why it's not finding it?
It appears that the CSS requests are being mistakenly routed to our react frontend, which returns the default react HTML page. I think this is probably caused by how our Nginx is setup. I can try setting this up on a more standard Rails service we have.
Does this match what a typical path should be for the CSS request?
/assets/audits1984/bulma.min-a0bcd487.css
Thank you so much @rosa 🙏 🙏🙏🙏. I merged https://github.com/basecamp/audits1984/pull/61 and will release a new version with it later today.
https://github.com/basecamp/audits1984/issues/50#issuecomment-2475775249
Hi is there any plan to release this soon?
