Is it possible to load entrypoints in Gemfiles from main application?

[vtt]

Supposed I have the following:

gem1:

app/frontend:
  ├── entrypoints:
  │   │── gem1.js 
  │── components:
  │   │ ── # other files
  │── stylesheets:
  │   │── gem1.css
  │── images:
      │── gem1.jpg

gem2:

app/frontend:
  ├── entrypoints:
  │   │── gem2.js 
  │── components:
  │   │ ── # other files
  │── stylesheets:
  │   │── gem2.css
  │── images:
      │── gem2.jpg

Is it possible to load the gem1.js and gem2.js entrypoints from main app?
ie: <%= vite_javascript_tag 'gem1' %> and <%= vite_javascript_tag 'gem2' %>

[ElMassimo]

Technically, you can always import gem1.js from an entrypoint in your application, by using an absolute path that resolves to the gem location in disk (or an alias).

If you are talking about Rails engines, take a look at this example setup with separate compilation, or this example where the assets can be referenced directly using aliases.

Could you describe the use case you have in mind? Normally you would package assets in an npm package instead of a gem, in which case you can import from the package as usual.

[Matt-Yorkley]

Just did a bit of hacking around on this and confirmed it works, but the given gem path also needs to be whitelisted under server.fs.allow otherwise Vite will (understandably) refuse to load assets from it;

export default defineConfig({
  resolve: {
    alias: {
      '@gem': process.env.GEM_PATH
    },
  },   
  server: {
    fs: {
     allow: [process.env.GEM_PATH]
    },
  },   
})

[ElMassimo]

You may also set server.fs.strict to false, but being explicit is better (and safer).

[Matt-Yorkley]

I've just been playing with the new additions from #162. Pretty nice!

Having to manually name each gem in the vite.rb file and then manually alias and whitelist them in vite.config.ts before being able to import their assets in an entrypoint is a bit cumbersome though. Maybe it's okay for 1 or 2, but if it started to get to 5 or 6 it might turn into a bit of a mess...

What do think about exposing all gem-based assets automatically? Something like this would work:

# config/vite.rb

# *All* the gems in a hash
ViteRuby.env['GEM_PATHS'] = Gem.loaded_specs.to_h{|name, gem| ["gems/#{name}", gem.full_gem_path] }.to_json

# config/vite.config.ts

import { defineConfig } from 'vite'
import FullReload from 'vite-plugin-full-reload'
import RubyPlugin from 'vite-plugin-ruby'
import StimulusHMR from 'vite-plugin-stimulus-hmr'

const gem_paths = JSON.parse(process.env.GEM_PATHS)

export default defineConfig({
  plugins: [
    RubyPlugin(),
    FullReload(['config/routes.rb', 'app/views/**/*'], { delay: 200 }),
    StimulusHMR(),
  ],
  resolve: {
    alias: gem_paths
  },
  server: {
    fs: {
      allow: [
        ...Object.values(gem_paths)
      ]
    }
  }
})

# app/frontend/entrypoints/application.js

import "gems/your_favourite_gem/assets/js/whatever_you_want.js"
import "gems/some_css_framework/dist/css/hot_theme.css"

With the new bundling options in Rails, it's becoming more normal for modern gems to include assets. https://github.com/hotwired/stimulus-rails/tree/main/app/assets/javascripts is an example.

What do you think?

[ElMassimo]

I'd like to wait and see how frequent this usage is for Vite Ruby users before expanding the API.

In the meantime, users can leverage config/vite.rb to implement a pattern like the one you described above.

Thanks for sharing! Feel free to open a new discussion to share this "recipe".

[mameier]

Vote up for this "recipe": good to keep all in sync for gems like actiontext, stimulus, ...
no need to find and install "matching" npm modules.