With sprockets-rails 3.0.0, teaspoon expects assets to be precompiled

[Capncavedan]

Ruby 2.2.4, Rails 4.2.5, updated to sprockets-rails 3.0.0 from 2.3.3, encountered an issue where teaspoon running jasmine tests expected assets to be individually precompiled.

Tried adding support/bind-poly.self.js to the initializer as suggested, but then encountered same issue with the next .js file.

I’m unsure why teaspoon mentions it is running in production as the output of p Rails.env run in its config file is “development”

Teaspoon running default suite at http://127.0.0.1:60921/teaspoon/default
Error: ActionView::Template::Error: Asset was not declared to be precompiled in production.
Add`Rails.application.config.assets.precompile += %w( support/bind-poly.self.js )`to`config/initializers/assets.rb`and restart your server
/home/travis/build/MerchantsBonding/hubble/vendor/bundle/ruby/2.2.0/gems/sprockets-rails-3.0.0/lib/sprockets/rails/helper.rb:350:in`raise_unless_precompiled_asset’

[jejacks0n]

which version of teaspoon? Have you checked master yet?

note to self: add teaspoon version display to the output so I don't have to ask.

[Capncavedan]

Hi @jejacks0n - this is teaspoon 1.1.1

[Capncavedan]

I did try the master branch just now, and received the same results.

[evbots]

I'm experiencing the same issue. Error: ActionView::Template::Error: Asset was not declared to be precompiled in production.

I'm on the teaspoon master branch

[jejacks0n]

http://stackoverflow.com/questions/34344094/after-gem-update-test-fail-with-asset-was-not-declared-to-be-precompiled-in-pr

The interesting thing is that teaspoon does register assets for precompilation as seen here:

https://github.com/modeset/teaspoon/blob/master/lib/teaspoon/configuration.rb#L24 https://github.com/modeset/teaspoon/blob/master/lib/teaspoon/engine.rb#L49

So my guess is that 1. teaspoon may be adding the precompile stuff at the wrong time (or it's being cleared out somehow?), 2. sprockets is looking at an incorrect environment (with production being noted in the exception?)

Those are my best guesses, so for now the work around would be to drop your sprockets version and we'll try to get to this when time permits. I've opened an issue on sprockets-rails as well.

[rafaelfranca]

@jejacks0n hi! I'm sprockets maintainer. What is happening is that teaspoon use javascript_tag to include the users' defined test files. Say you have the test/javascript/unit/home_test.js file. Teaspoon call javascript_tag with that as argument. That file is not registered for precompilation and sprockets-rails 3 now is strict about files that are being used as argument to javascript_tag and not being in the precompile list.

Does teaspoon maintain a list of all the test files? If so it is possible to register them?

I'm using teaspoon with sprockets-rails 3 and we are correctly doing to workaround this problem is:

config.asset_manifest += [%r{^unit/}]

But I'd love to get ride of it since teaspoon already know which files are being called in javascript_tag and can register them.

[jejacks0n]

Thanks @rafaelfranca! Teaspoon does the lookup at the time of execution, not at the time the engine is loaded -- this is so new files can be added and they'll show up.

Can we register assets without them stacking after the initial load -- at the time of execution basically? If so, we can add that call in the controller which should mean they're registered before trying to serve them. We'd collect all the "root" paths for assets that we're going to load, and register those.

We could also do something similar to what you've done and introduce it at load time, but it's not as simple because the configuration uses a glob path for where to look for spec files, and so would have to parse the paths out of that and register them in sprockets.

[jejacks0n]

@rafaelfranca since you're here. =) Is there a way that we could move to help Teaspoon be less coupled to sprockets? There's been breaking changes with most releases of sprockets -- which is reasonable given that Teaspoon is an outlier in usage patterns. We haven't yet found the right balance to keep things functional and capture the feature set desired for a test runner and I'm curious if you have any advice or ideas.

[rafaelfranca]

I think we can extend the precompiled_asset_checker in the view instance to use the controller information https://github.com/rails/sprockets-rails/blob/master/lib/sprockets/railtie.rb#L205.

Something like

self.precompiled_asset_checker = -> logical_path { Rails.application.asset_precompiled? logical_path || @suite.spec_assets.include? logical_path }

[jejacks0n]

Ah, thanks for the info. Will try this week to get that implemented on my end.

You get what I'm getting at with the coupling though? Even that precompiled_asset_checker method isn't part of an external API, so if that gets changed it will break Teaspoon.

My objective is to try and get a more complete/robust API from sprockets that can be more stable. I can provide a write up of areas of pain, and work towards that by contributing back to sprockets.

[jejacks0n]

Worth noting, the coupling has been better recently, and we were able to remove most (if not all) areas where we had to branch based on the sprockets-rails version.

[rafaelfranca]

We can consider that option as part of public API, but yeah, give me a write up with the areas of pain and we can find a solution together.

[jejacks0n]

The recommended fix is to drop the sprockets version until this is addressed in master and released.

[mfazekas]

FWIW: As a workaround i'm having this horrible monkey patch in my taspoon_env.rb:

module RaiseUnlessPrecompiledFixer # see https://github.com/modeset/teaspoon/issues/443
  def raise_unless_precompiled_asset(path)
    super unless path.split('.')[-2] == 'self'
  end
end
...
Sprockets::Rails::HelperAssetResolvers::Environment.send(:prepend,RaiseUnlessPrecompiledFixer)

[sb8244]

We did this monkey patch:

module ExcludeSpecFromPrecompile
  def asset_needs_precompile?(source, filename)
    super unless filename.include?("spec/javascripts")
  end
end
Sprockets::Rails::Helper.prepend(ExcludeSpecFromPrecompile)

This is the least intrusive and obvious way we thought of doing it. It only happens when teaspoon is running, so won't be a production issue

[jejacks0n]

@sb8244 that's a great solution. Would you be willing to submit a PR where that is injected from within engine.rb? I would merge it and release. I've been out for the holidays and sick. :-/

[sb8244]

@jejacks0n I would be happy to

What do you think of creating a method in engine that does the little hack (sort of like is already there) and only executing that method when Sprockets::VERSION.split(".")[0].to_i >= 3. This way old sprockets won't be needlessly patched

[jejacks0n]

that sounds perfect.

[jejacks0n]

@mikepack just brought up a good point.. that path, is a glob path, and can be test/javascripts, or anything else you wanted it to be.

[sb8244]

Good point, a glob for standard names would be great.

Should a configuration option be exposed as well? This would allow someone to specify their own exemptions

[jejacks0n]

I think Teaspoon.configuration.asset_paths would be essentially that. That's an array of paths that are rails root relative. It seems like doing what you're doing for each of those paths would work, though I don't know how that would impact performance. Let's give that a shot.

[jejacks0n]

To clarify, the glob path in conjunction with the asset paths configuration in teaspoon env is what enables putting test/spec files where you want them. I think we can use the asset paths configuration to determine if they're servable in an asset path teaspoon knows about, but they can also exist within your application asset paths, and teaspoon wouldn't know about those.

[NealJMD]

We're experiencing this issue too. Thanks for working to address it!

[jejacks0n]

Digging into the code a bit I found what seems to be a relatively easy fix, but the proposed solution may need some review and discussion first.. it may also leave teaspoon sort of broken with a specific version combination, which we'll have to probably work around anyway.

If you want to keep up on that part of the discussion, check https://github.com/rails/sprockets-rails/issues/297

I'm using that one, because it's more tied to rails, as the proposed code change is in action_view.

[jejacks0n]

Teaspoon 1.1.2 was released. Update and see if it's working for you.

[ajb]

Thanks for all the effort! Unfortunately this 1.1.2 is not working for us. It looks like the #= require directives are not actually resulting in the JS getting included.

[jejacks0n]

@ajb, that doesn't seem related. If you're not getting an error when trying to load files that aren't in your precompile list I'd suggest looking at other issues, or creating a different one.

[psharpNumerex]

The rails 4.2.5.1 upgrade seems to have broken the fix.

Teaspoon tests were working fine prior to upgrading this morning, broken with:

Error: ActionView::Template::Error: Asset was not declared to be precompiled in production. Add Rails.application.config.assets.precompile += %w( support/bind-poly.self.js ) to config/initializers/assets.rb and restart your server

immediately after

[jejacks0n]

@psharpNumerex fixed as of #450, released version 1.1.3 so update and test. =)

[psharpNumerex]

Updated, still fails and when I look at the source in bundle show teaspoon, I see this in engine.rb:

if ActionView::VERSION::STRING == "4.2.5" || ActionView::VERSION::MAJOR >= 5

edit: looks like the 1.1.3 tag is off the rails_5 branch

[robgoodberry]

I was running into the same thing and after updating to 1.1.3 I received an error telling me to include teaspoon-qunit in my Gemfile. I did so and then received this again after:

Error: ActionView::Template::Error: Asset was not declared to be precompiled in production.
Add `Rails.application.config.assets.precompile += %w( support/bind-poly.self.js )` to `config/initializers/assets.rb` and restart your server

[jejacks0n]

So, funny thing.. I released the rails_5 branch as Teaspoon 1.1.3.. dang.

I'm releasing 1.1.4 before I leave today.

[merwan]

With v1.1.4 we don't need the monkey patch in teaspoon_env.rb anymore.

[aneta-bielska]

ruby 2.1.5, Rails 4.2.4, teaspoon 1.1.4, sprockets 3.5.2 Should I use different versions or there is another reason why it's still filing? (should I open new issue?)

Error: ActionView::Template::Error: Asset was not declared to be precompiled in production.
Add `Rails.application.config.assets.precompile += %w( support/bind-poly.self.js )` to `config/initializers/assets.rb` and restart your server

[robgoodberry]

@aneta-bielska that looks like the error I had with teaspoon <= 1.1.3. 1.1.4 is in your Gemfile.lock?

[aneta-bielska]

@robgoodberry yes, it is 1.1.4

[b1nary]

I am running into the same issues with 1.1.4. The monkey patch from @mfazekas is working for me. I've tried Sprockets 3.2 and 3.5.2. Rails is 4.2.2.

My Solution meanwhile

# https://github.com/modeset/teaspoon/issues/443
gem 'sprockets', '3.2.0'
gem 'sprockets-rails', '2.3.1'

[mihai-dinculescu]

Minor note, locking sprockets-rails to the latest 2.X version should be enough for the workaround.

gem 'sprockets-rails', '~> 2.0'

This will allow you to get security updates for both sprockets and sprockets-rails.

[thbar]

I faced the same issue with 1.1.4. Updating to master today (2.4.1) fixed it.

[sb8244]

I'm getting the same issue as @ajb. The asset is "compiling" but it isn't actually requiring anything through sprockets. It is just generating an empty file. This is on the latest teaspoon, rails 4.2, and teaspoon-jasmine.

[sb8244]

Confirmed that 1.1.5 isn't compiling my assets into the final product. 1.1.4 works correctly although has the issues previously mentioned above.

I had to change the above (hacky) script to the following for the updated sprockets:

module ExcludeSpecFromPrecompile
  def precompiled?(path)
    return true if path.include?("spec.js") || path.include?("spec_helper.js")
    super
  end
end
Sprockets::Rails::HelperAssetResolvers::Environment.prepend(ExcludeSpecFromPrecompile)

[ur5us]

Just upgraded an app from Rails 4.2.9 to 4.2.10 and this error started happening. Downgrading sprockets-rails to 2.x fixes the issue. For the moment, I don’t see anything in Rails 4.2.10 related to the issue :(

[agrobbin]

@ur5us I'm not sure if you're still running into this issue, but after running into it myself with Rails 4.2.10, I narrowed it down to an issue with the version comparison for the javascript_include_tag patch last updated in #461. I issued #529 to fix the problem longer-term.

While waiting for that fix to (hopefully) be merged and released in a new version of Teaspoon, copying the patch from lib/teaspoon/engine.rb should fix the problem (at least, it did for me)!

[arielscherman]

@agrobbin Your fix hasn't been merged yet... are you aware of any reason? I am facing the same issue.

[erlandsona]

Rails 4.2.0 Sprockets-Rails 3.2.0 Sprockets 3.7.1 teaspoon 1.1.5 teaspoon-jasmine 2.3.4

Any updates on this issue?

[agrobbin]

@arielscherman unfortunately I'm not. I've not yet heard back on #529 from a contributor/owner to this repo.