How to run system specs without recompiling assets every-time

[templeman15]

@ElMassimo first off thank you for all your work, vite_ruby is amazing!!

I am reaching in regards to this:

First on the list is an integration test that can trigger a Hot Reload, and check the updated style or code.

I'm trying to run my system specs (Capybara / RSpec) and every time the assets need to be compiled and fail the system spec with a NetTimeout. After the assets compile I can run the tests successfully. This flow is not opportune at all however, I'd really love to see hot reloading take place (maybe running bin/vite --mode=test or something along those lines so the assets don't need to go through the full recompilation process before being able to run the specs.

Do you have any idea how to accomplish this? I don't see much at all in Vite or Vite Ruby (or google) that go into any depth on testing.

Thanks!

[ElMassimo]

Edit: now possible, see this answer.

---

I haven't tried it, but Vite.js added a watch mode that might do the trick.

Run bin/vite build -- --watch to start the Rollup watcher.

If using vite_ruby@3.0.1 or higher, you can run bin/vite build --watch.

Then, make sure that autoBuild is disabled or it will attempt to rebuild assets, since the build process never finished and it never recorded a success/failure.

---

It should be technically possible to run tests with a Vite.js server running, but it's not advisable because you wouldn't test the behavior of the compiled JS in production.

bin/vite dev
# and then override the Rails environment:
VITE_RUBY_MODE=development bin/rspec

[templeman15]

I have also tried out this plugin.. It seemed promising but failed to render the chunks if we had this setting preserveModules: true, which it says is required.

[ElMassimo]

How does it fail? That seems promising if the build is taking too long.

Thanks for replying above. Are you using React?

Using Vue the transforms are really fast because they avoid a full babel AST parse, so I haven't run across a project that takes that long to build.

[templeman15]

Thanks for responding back!

It just gets to the point where it usually says rendering chunks in the build process but hangs there. With --verbose it also gives no additional output.

We have a very large monolith that used webpack. It was taking 30-60 seconds to do incremental builds for every code change. Vite gets that to 50-100ms, which is fantastic! But this is the only thing hinging us on releasing it to the team. We can't really write tests effectively and run the tests as we are developing.

In the output of Vite we are getting css (scss), JavaScript (react), JavaScript (svelte), fonts, SVGs, vendor (which is very large).

[ElMassimo]

Gotcha, have you tried profiling which plugins are taking longer?

I've thought about it, and I think it would be nice to leverage the Vite dev server when running tests locally—it's a reasonable trade-off as long as the CI does a production build, and it could fallback to autoBuild if the server is not available.

If you prepare a repo with some of the libraries and Vite plugins you are using (such as React and Svelte), I can take a look and see what's necessary in terms of environment flags to get HMR working on Rails with RSpec, and supporting it as a mode in Vite Ruby.

[templeman15]

I really appreciate it! If you need any assistance and can point me in the right direction I can open a PR if needed! I do think however making testing front of mind will be big for the community, particularly in regard to Ruby / Rails and Vite!

I will try and spin up a repo at least with rails and react how we have it setup tomorrow or over the weekend! I also agree with the trade offs you mentioned, ideally just running one Vite dev server and not one for dev and test.

I will also try profiling the plugins. Is there a way of doing that during the build process or what do you recommend?

[ElMassimo]

Using a Vite dev server when running tests is now supported out of the box, starting from vite_ruby@3.0.2.

Added a test in the example Rails app that rewrites files and verifies that HMR is working.

@templeman15 Run bin/vite upgrade, give it a try, and let me know how it goes 😃

---

Related: Found that sourcemaps were generated when building in test mode, which is unnecessary and would really slow down the build in an app like the one you described. Running bin/vite upgrade should also upgrade to vite-plugin-ruby@3.0.3 which includes this fix.

[templeman15]

1. I will try that!

2. Ahh that's great! To clarify, I'lll need autoBuild: true in test for that behavior?

[ElMassimo]

@templeman15 Yeah, which comes by default in the installation process.

Regarding the lack of output when the build is triggered during tests, have in mind that Vite Ruby uses the Rails logger, which in the test environment it's often configured to output to a file instead of the terminal (log/test.log).

If you want to see the output, you could manually assign a stdout logger to ViteRuby.instance.logger in spec_helper.rb, or change the default behavior of the Rails logger in the test environment.

[templeman15]

Awesome, thank you for all your help!

[templeman15]

Just updating you after getting everything wrapped up.

I did not end up running just one Vite dev server. This took env vars for development and placed them into the test environment. I instead created an npm script along with the concurrently package to run both dev servers in one terminal session.

yarn add concurrently

package.json:

"vite": "concurrently -n vite-dev,vite-test \"bin/vite dev\" \"bin/vite dev --mode=test\""

---

I'm getting a lot of this output now (for source maps that were turned off):

---

I ran into a lot of problems pushing to CI with using react_on_rails because it's set up for webpack. I finally solved it by updating react_on_rails and setting REACT_ON_RAILS_PRECOMPILE=false on CI.

Thanks again!

[ElMassimo]

Thanks for sharing!

In case it's useful, my favorite way to run several processes is overmind, which is Procfile-based, and automatically creates a tmux session with one process per tab that you can connect to independently to see output or interactively debug.

Example, which I run using a dev global alias (overmind s -f Procfile.dev) that works on every repo with a dev Procfile.

You could extend the idea to a Procfile.test, to start the necessary Vite test server.

[zealot128]

I "Fixed" the Timeout error, by simply running the build once before all system specs:

RSpec.configure do
  config.before(:all, type: :system) do
    puts "\e[31mPrecompiling assets for system specs \e[0m"
    ViteRuby.instance.manifest.resolve_entries('application', type: 'js')
    puts "\e[32m-> Finished! precompiling assets for system specs \e[0m"
  end
end

That fixes the Timeout Issues for me (Using Cuprite the Ferrum::TimeoutError, Ferrum::PendingConnectionsError errors).

[ElMassimo]

You should prefer ViteRuby.commands.build instead, as it's more explicit. The build will be skipped if it's up-to-date.

Additionally, when running integration tests in the CI, it might be preferable to run bin/rake assets:precompile before running specs (separates time spent precompiling assets from time spent running tests).

[zealot128]

You should prefer ViteRuby.commands.build instead, as it's more explicit. The build will be skipped if it's up-to-date.

Additionally, when running integration tests in the CI, it might be preferable to run bin/rake assets:precompile before running specs (separates time spent precompiling assets from time spent running tests).

@ElMassimo Thanks for the info. Did not find the command and just read the Tag Helper where I found the resolve_entries command. I will use the one you wrote.
Yes, in CI we also run a rails assets:precompile beforehand. But locally it is often frustrating when you run a single spec and you get a Timeout once everytime you modify the assets. Before, I event had a rescue clause, that catches the Timeout, and rerun the visit call in the first spec, which was tedious.

[ElMassimo]

The way I deal with it locally is by using a different Cuprite timeout in development:

  # Unlike the capybara timeout, which should be very short to ensure test fail
  # fast, this timeout needs to be long to ensure we give enough time for assets
  # to be precompiled.
  #
  # You can increase this value in `.env.development.local` in slower matchines.
  cuprite_timeout = ENV.fetch("CUPRITE_TIMEOUT", 30).to_i

and then:

    timeout: cuprite_timeout,
    process_timeout: cuprite_timeout,

while keeping the Capybara timeout strict:

Capybara.configure do |config|
  config.default_max_wait_time = 3
end

But being explicit and running a build for system specs makes sense. It might be a good idea to create a Testing section in the Vite Ruby guide.