raise_runtime_errors is not working with recent sprockets

[rafaelfranca]

From @rosenfeld on December 28, 2015 18:39

From the official guides:

http://guides.rubyonrails.org/asset_pipeline.html

"3.1 Runtime Error Checking By default the asset pipeline will check for potential errors in development mode during runtime. To disable this behavior you can set:

config.assets.raise_runtime_errors = false

When this option is true, the asset pipeline will check if all the assets loaded in your application are included in the config.assets.precompile list."

This indeed used to work with previous versions of sprockets but when I tried to upgrade it stopped working. You can easily reproduce it by running "rails new demo" using latest Rails (4.2.5). sprockets 3.5.2 is installed currently and sprockets-rails 3.0.0 will always generate an "Asset was not declared to be precompiled in production" error.

It assumes it's always an error to not add the asset to precompile but for my use case I need a way to circumvent this error. I use an approach to test my client-side code that will require only the dependencies for a given test, so that I can be sure all dependencies are fully specified for my JS modules. The testing framework will then include individual assets that shouldn't be precompiled because those individual compiled files won't be sent to production and are only using in the test and development environments.

Could you please get raise_runtime_errors back to work with recent versions of sprocket/sprocket-rails?

Copied from original issue: rails/rails#22813

[rafaelfranca]

Yes, we are aware of it. It was one of the main changes in sprockets-rails 3.

Could you please get raise_runtime_errors back to work with recent versions of sprocket/sprocket-rails?

No. That option was made optional before because we introduced in a minor version. Now that we released a major version I don't see any reason to disable that check that was made to avoid surprising errors.

I use an approach to test my client-side code that will require only the dependencies for a given test, so that I can be sure all dependencies are fully specified for my JS modules. The testing framework will then include individual assets that shouldn't be precompiled because those individual compiled files won't be sent to production and are only using in the test and development environments.

If you are talking about teaspoon they have how to handle that without you needing to disable that check. Just to be clear I use this same approach in Shopify test suite without to having to disable this check. If you are not using teaspoon, you can also handle that without needing to disable the check. If you know the files that need to be included you can also use this information to tell the checker to not raise the error for those files.

[rafaelfranca]

From @rosenfeld on December 28, 2015 23:46

I'm using my own framework and runner. How can I allow it to include the debug dependencies without getting into this error?

[rafaelfranca]

I had not check that yet but you can use precompiled_asset_checker as I commented here https://github.com/modeset/teaspoon/issues/443#issuecomment-166371352. If that doesn't work we should make it work.

[rosenfeld]

Hi @rafaelfranca, I'm not sure teaspoon is using your suggestion as I can't find any references to precompiled_asset_checker in its source code. The strategy we use for testing (Konacha, Teaspoon, OOJSpec and every other test runner built on top of rails-sandbox-assets) rely on serving individual assets which are not meant to be individually compiled to send to production.

precompiled_asset_checker doesn't sound like the proper solution to this problem. It names suggests the proc should check whether the asset is precompiled or not and use it for something completely different sounds a lot weird to me. Also, it makes things more complicate, not simpler. The requirement is very simple. We want to be able to serve some assets bypassing the precompiled check. An ideal option would be something like:

stylesheet_link_tag *dynamic_assets, debug: true, skip_precompiled_check: true

This should resolve the issue with all those test runners integrated with the Rails Assets Pipeline.

After all, I want to take advantage of the feature that will raise everytime we forget to add an asset to the precompiled list for the application and only skip it for my tests. I often run my JS tests from the development environment, so I'd prefer to avoid setting a different checker based on the environment. Would you consider a solution which provided some special option to stylesheet_link_tag and javascript_include_tag?

[rosenfeld]

Also, how do I know when the precompiled_asset_checker already exists? Should I write an initializer? If so, what should I pass to the after option? Or should I use something like ActiveSupport.on_load(:sprockets_rails) do? In the latter case, I think this would have to be implemented by sprockets-rails.

[rosenfeld]

I could get it to initialize like this:

Rails.application.config.after_initialize do
  ActiveSupport.on_load(:action_view) do
    default_checker = ActionView::Base.precompiled_asset_checker
    ActionView::Base.precompiled_asset_checker = -> logical_path do
      default_checker[logical_path] || @tests
    end
  end
end

But @tests is always nil even when it is defined in the controller and I couldn't find any way to get the request context. Any ideas, @rafaelfranca?

[rosenfeld]

The only solution I could come up with is by using Thread.current[:skip_precompiled_check] in an around_action block and in the new checker... But all of this seems like the wrong way to handle this issue...

[rosenfeld]

This is how I fixed rails-sandbox-assets for the time being:

https://github.com/rosenfeld/rails-sandbox-assets/commit/1d2b5c2fa06dab11eb96357648cbad39ad5c5586

[alexkravets]

@rosenfeld please check out how this issue has been resolved in konacha: https://github.com/alexkravets/konacha/commit/f049dcf482b70f77cca3c002aeee99170c9f95ee

[rosenfeld]

Thanks, @alexkravets. I'm in the process of moving our resources build system from sprockets to webpack due to several reasons, like support for source-maps, ES6 (Babel), code splitting, ability to join some CSS rules inside a JS chunk to reduce the amount of lazy requests, ability to easily use and manage npm and bower packages and other reasons. So, it's likely I'll end up moving oojspec to some npm package and integrate it to karma and webpack for running my tests... But thanks anyway for sharing your solution!

[christopher-haueter]

Is https://github.com/jfirebaugh/konacha/issues/216 related to this issue? That issue just got closed recently.

[ghost]

NoMethodError - undefined method `first' for #Sprockets::Asset:0x0000000c0cbd70: