Rails engines integration

[denjamio]

Has someone set vite-rails on an engine? how would it fit with the main app? thanks for working on this project

[ElMassimo]

@denjamio Check out this example Rails engine which is used in the example Rails app.
See a live example.

That's the minimal setup required to get HMR when a dev server is running, and ensure it doesn't delete assets from the parent app.

There's definitely room for improvement, specially when it comes to deployment.

Make sure to use vite_ruby@1.2.16, as it contains a few improvements for the engine use case.

[BilalBudhani]

@ElMassimo I'm trying to follow the above example Rails engine code to integrate Vite Rails in my engine. However, after following all the steps I'm getting the following error:

/Users/bilalbudhani/Code/adminx/lib/adminx/engine.rb:8:in `vite_ruby': uninitialized constant Adminx::Engine::ViteRuby (NameError)
        from /Users/bilalbudhani/Code/adminx/lib/adminx/engine.rb:13:in `<class:Engine>'
        from /Users/bilalbudhani/Code/adminx/lib/adminx/engine.rb:2:in `<module:Adminx>'
        from /Users/bilalbudhani/Code/adminx/lib/adminx/engine.rb:1:in `<top (required)>'
        from /Users/bilalbudhani/Code/adminx/lib/adminx.rb:2:in `<top (required)>'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:66:in `require'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:66:in `block (2 levels) in require'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:61:in `each'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:61:in `block in require'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:50:in `each'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler/runtime.rb:50:in `require'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/bundler-2.2.20/lib/bundler.rb:174:in `require'
        from /Users/bilalbudhani/Code/adminx/test/dummy/config/application.rb:7:in `<top (required)>'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/commands/server/server_command.rb:138:in `block in perform'
        from <internal:kernel>:90:in `tap'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/commands/server/server_command.rb:135:in `perform'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/command/base.rb:69:in `perform'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/command.rb:48:in `invoke'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/commands.rb:18:in `<top (required)>'
        from /Users/bilalbudhani/.asdf/installs/ruby/3.0.1/lib/ruby/gems/3.0.0/gems/railties-6.1.4/lib/rails/engine/commands.rb:9:in `<top (required)>'
        from bin/rails:14:in `<main>'

Do you think there is a step missing in the above example? Because I can see in your example Rakefile contains some ViteRuby related code which isn't mentioned in the README, thou I tried updating my engine's Rakefile as well but still I couldn't get it working.

[ElMassimo]

Hi @BilalBudhani! The error seems to be related with ViteRuby not being loaded.

Have you added vite_rails as a dependency in the engine's gemspec?

[BilalBudhani]

Yes, I do. I actually went through the steps multiple times to ensure I've followed them properly and everything is as per the README file in the sample project. I'm not sure why It cannot find ViteRuby.

[ElMassimo]

Can you try requiring it manually in the engine file? require 'vite_ruby'

Also, if you are using the classic Rails autoloader, it might be a good idea to try explicitly referring to it as a top-level constant: ::ViteRuby.

[BilalBudhani]

@ElMassimo requiring 'vite_ruby' in engine.rb made it work. Thanks!

[did]

hey all, I've been working on a Rails engine (https://github.com/maglevhq/maglev-core) and recently I've switched over to Vite Ruby.
I use my engine in production in various Rails applications, some running Webpacker and others Vite as the main asset processor.
So thanks you @ElMassimo for your amazing work!

However, I had to modify the Rails Vite engine template:

• I was facing a really weird issues in production. For instance, the ViteRuby::DevServerProxy middleware was still added in the rack stack. It turns out that the Vite env pointed to development. The fix was easy: https://github.com/maglevhq/maglev-core/blob/master/lib/maglev/engine.rb#L44
• I didn't want to manually copy the engine compiled assets to the main app so I wrote some rake tasks for that: https://github.com/maglevhq/maglev-core/blob/master/lib/tasks/maglev_tasks.rake#L58. Warning, this requires to add a Rack::Static middleware to serve the assets in production (but when using a CDN, that's fine) https://github.com/maglevhq/maglev-core/blob/master/lib/maglev/engine.rb#L48

Hope it will help other developers.

[ElMassimo]

Thanks for sharing!

The behavior is to take Rails.env as the mode, so perhaps Rails.env in the engine is set to development. Seems like Rails.env is development for the engine?

Vite Ruby has some support for rake tasks in engines, it might be tricky to setup but it shouldn't require copying tasks manually. I'll check to see what's missing in the setup to achieve this.

[did]

thanks for the answer!

The behavior is to take Rails.env as the mode, so perhaps Rails.env in the engine is set to development. Seems like Rails.env is development for the engine?

Ok, super weird. this wasn't the behavior I saw in my 2 in production apps. (btw, I wasn't aware that Rails.env could get a different value within an Rails engine.)
Even weirder, if I remind it correctly, on one of the applications, the CD/CI fails randomly because of the public_output_dir which will be randomly take the value defined in the vite.json file under the development scope and the default vite value.
By forcing it in my engine, it solved all my issues.

Vite Ruby has some support for rake tasks in engines, it might be tricky to setup but it shouldn't require copying tasks manually. I'll check to see what's missing in the setup to achieve this.

👍🙏

[jrochkind]

If you are running a rake task, default Rails.env will always be development, for the duration of that rake task. I can't quite tell what your situation is or if that's relevant, sorry if it's not.

[mattalat]

@did please forgive me if this is a silly question, but why do you need to copy the compiled assets at all? Is it because you do not have vite ruby configured in the main app?

I ask because I have a use-case that sounds similar to yours where I would like an engine (packaged as a gem) to deliver a standard set of assets and Rails front-end bits (helpers and views) to apps that require it. I was imagining I could keep all of the compilation isolated to the main app (as long as it too used vite-ruby) and simply require the engine's vite setup.

My hope was that this could allow things like app overrides to libraries that are brought in by the engine, such as tailwind-css, which would require the engine's assets to be available, un-compiled, to the main app.

[did]

@mattalat. Not a silly question. This is exact, I didn't want to force developers to install / setup vite_ruby in the main application.

It's personal choice and there is no good/bad decision but in my case, there was also a chance that the developers use a different version (newer or older) of Tailwindcss in the main application. To avoid conflicts, I decided to isolate Tailwindcss from the main app.
And the negative side of it is that developers can't override the UI of the engine UI but that's okay for me.
Besides, to modify the UI, they would have to change the VueJS component sources and recompile them from the main app which sounds too complex to me.

If your engine use case involves the developers to heavily modify the behavior of the engine UI/UX, in that specific case, I believe copying the engine JS/CSS assets to the main app and providing the tooling to compile them along the other main app assets could be a solution.