Vite #1882
Vite #1882
Conversation
bundle exec vite install But we changed things over to generic app/frontend, not app/javascripts that the install script wanted to use seeing we already had webpacker. We want to keep them separate. Also we have not committed the Procfile.dev for now, I don't think we'll use foreman.
|
Vite-rails has some special instructions for deploying with heroku... but they don't appear to me to be necessary right now. And based on what they do, it definitely seems better to avoid them if not necessary. https://vite-ruby.netlify.app/guide/deployment.html#using-heroku |
|
I was having some mysterious problems that went away with |
|
While we will leave this in draft mode while we do more vite work, this initial step is ready for a review, @eddierubeiz! And would be convenient to get one before i start doing more vite work. Note: * While things should work without it, you may choose to run the vite dev server in development. Just run: |
In our heroku deployment, our Rails app is directly serving assets (then cached by cloudfront). Under sprockets/webpacker, .gz alternates were created on asset build. And Rails will then automatically use these to serve content-encoded gzip content to clients which advertise accepting that. We lost that in initial vite migration, resulting in performance loss in deployed apps, as clients were not getting compressed .js and .css. This should fix that. ElMassimo/vite_ruby#281
Remove browser JS polyfills no longer required for current supported browsers
Make vite create .gz (and brotli) alternatives for built assets
Don't move it over to vite. We weren't using it. if we ever want to use it, we'll have to figure out how to add it back in via vite
With weird workaround to prevent Blacklight sprockets-included JS from triggering strict mode, which breaks current version of blacklight_range_limit JS
Unclear exactly what default is or how to turn off in prod. ElMassimo/vite_ruby#285
Move as much JS as possible from sprockets to vite
This PR will leave CSS and static file assets (like images) in sprockets for now.
Also we will leave blacklight JS in sprockets for now, even though theoretically
blacklight-frontendwould allow us to shift it over, there are just some complexities we're going to handle separately. Including what it's dependencies do to our node_modules tree (projectblacklight/blacklight#2849), and the desire to move CSS over to vite too, so we can have Blacklight CSS and JS both from the sameblacklight_frontendversion.This will, hopefully, leave us in a place no worse than our previous webpacker situation (no more confusing or hard to maintain), so can be merged and deployed, and even keep living like this for a while.