If webpacker hasn't built the expected bundles yet, 💥

[searls]

If the template computes an expected bundle path and it's not present (because WDS isn't running or because the app hasn't been run in dev mode and built it upon request), then the tests will fail.

This seems probably due to how we're launching the rails server—there must be some flag to compile webpacker via an executor hook in our test server so that this does not happen.

[Rukomoynikov]

I can be wrong, but it has to work in another way. Like before starting tests, you need to precompile assets. It is the same as database migrations.

[searls]

I tried and can't replicate this. Closing for now until I can

[vfonic]

@searls we just hit this issue when we were setting up cypress-rails for the first time on CircleCI.

The issue happened because we would first run bundle exec rails cypress:run before our step that was creating webpack(er) build: bundle exec rails assets:precompile.
This would actually only make first one or two tests fail (until the webpack produced the build). The rest of the cypress tests would pass afterwards.

When we moved the webpack build step before the cypress step, everything was fine.

Perhaps this could be added to README or run automatically by cypress-rails?

[searls]

I'm not familiar with other libraries forcing this onto users. I wonder if there's some API the gem could be calling to ensure Webpacker or Sprockets assets are compiled for test?

[searls]

I have some ideas in how we might spelunk through the rails code to understand who and when calls the asset compilation stuff, but it won't do me much good until I can repeatedly reproduce this problem and I have so far failed to reproduce it.

If you could provide a repo and/or reproduction steps that'd be a great help

[vfonic]

Here you go, sir:
https://github.com/vfonic/cypress_compiling

I've also tried to make each commit very small and explain exactly what I did in each commit:
https://github.com/vfonic/cypress_compiling/commits/master

The repro steps are in README.

[searls]

I am unfortunately not able to repro this. Try as I might, the on-demand webpacker compilation works fine:

[vfonic]

Ahhhhh, sorry, I re-read the issue again.

We're talking about two separate issues.

This would actually only make first one or two tests fail (until the webpack produced the build). The rest of the cypress tests would pass afterwards.

So it works for us the same way as it is for you. But at first it was confusing to find that first couple of cypress tests timed out. We looked in those tests, looking for errors, but the issue was that webpacker would kick-off the building of frontend assets.

I guess this is more of our oversight, but perhaps this should be added to the README or maybe as a warning in the logs?

[patbl]

I'm running into an issue that sounds like this one. This is the error I'm getting from the Rails server:

Completed 500 Internal Server Error in 1861ms (ActiveRecord: 0.0ms | Allocations: 1217952)
Asset `webpack_bundles/runtime-bundle.js` was not declared to be precompiled in production.
Declare links to your assets in `app/assets/config/manifest.js`.

  //= link webpack_bundles/runtime-bundle.js
and restart your server
Asset `webpack_bundles/runtime-bundle.js` was not declared to be precompiled in production.
Declare links to your assets in `app/assets/config/manifest.js`.

  //= link webpack_bundles/runtime-bundle.js
and restart your server excluded from capture: Not configured to send/capture in environment 'test'

ActionView::Template::Error (Asset `webpack_bundles/runtime-bundle.js` was not declared to be precompiled in production.
Declare links to your assets in `app/assets/config/manifest.js`.

  //= link webpack_bundles/runtime-bundle.js
and restart your server):
    77:
    78:   <% unless @no_sitewide_js %>
    79:     <%=
    80:       env_javascript_include_tag(
    81:         static: 'webpack_bundles/runtime-bundle',
    82:         hot: "#{ENV['HOT_RAILS_ORIGIN']}/webpack_bundles/runtime-bundle.js",
    83:       )

app/views/layouts/_dependencies.html.erb:80

Does anyone know whether this is the same issue or something else?