You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Yes - a problem in a slightly idiosyncratic setup we're looking at.
Describe the solution you'd like
We're setting up a frontend microservice within an existing Rails project running a legacy Webpacker setup. As we look to update our stack, we're setting up a subfolder from the Rails root, running its own package.json and built using Vite.
The challenge here is (please correct me if I'm mistaken!) there's no option to specify the location of the vite.config.ts file. With our new structure, if we keep this file at the root level, it has incorrect dependencies ascertained from the legacy setup. If we move it to the subfolder, there's no way for vite_ruby to change where it looks for this.
I've managed to very scrappily patch your gem locally to accept a --js-config-path argument specifying the nested vite.config.ts location, and all works pretty well. (Happy to share if you're interested, but it really is crude work designed to see if this were a possibility.)
It would be lovely if this functionality were built in, perhaps by using either a config argument and / or an ENV variable.
Describe alternatives you've considered
We've hit dependency hell, hence our unorthodox approach. The alternatives would be a major change to upgrade everything at once, or to use a frontend build tool independent of Rails and handle the new microservice manually.
Thanks for the time reading through this - let me know if you've any questions, advice, etc. :)
The text was updated successfully, but these errors were encountered:
I haven't had too much joy configuring the root - that was my first port of call when coming to this, but I've been hitting an error I haven't been able to get past:
No such file or directory - folder_name (Errno::ENOENT)
I've no idea why, that seemed like the perfect solution. Permissions etc OK for the directory 🤷
Seems to originate in ViteRuby::IO with this code: Open3.popen3(*cmd, **opts). The option to change the directory is set: {:chdir=>#<Pathname:folder_name>}, but it appears I'm already in the directory at that point:
> system 'pwd'
rails_root/applications_app
=> true
Perhaps I'm looking at a bit of an XY problem and if I overcome that everything'll fall into place?
Is your feature request related to a problem? Please describe.
Yes - a problem in a slightly idiosyncratic setup we're looking at.
Describe the solution you'd like
We're setting up a frontend microservice within an existing Rails project running a legacy Webpacker setup. As we look to update our stack, we're setting up a subfolder from the Rails root, running its own package.json and built using Vite.
The challenge here is (please correct me if I'm mistaken!) there's no option to specify the location of the
vite.config.ts
file. With our new structure, if we keep this file at the root level, it has incorrect dependencies ascertained from the legacy setup. If we move it to the subfolder, there's no way forvite_ruby
to change where it looks for this.I've managed to very scrappily patch your gem locally to accept a
--js-config-path
argument specifying the nestedvite.config.ts
location, and all works pretty well. (Happy to share if you're interested, but it really is crude work designed to see if this were a possibility.)It would be lovely if this functionality were built in, perhaps by using either a config argument and / or an ENV variable.
Describe alternatives you've considered
We've hit dependency hell, hence our unorthodox approach. The alternatives would be a major change to upgrade everything at once, or to use a frontend build tool independent of Rails and handle the new microservice manually.
Thanks for the time reading through this - let me know if you've any questions, advice, etc. :)
The text was updated successfully, but these errors were encountered: