Works in dev but not in production(?)

[marks]

Here's what I have in my app.rb.

require 'sinatra/assetpack'
Sinatra::Application.register Sinatra::AssetPack

assets do
  serve '/js', :from => "assets/js"
  serve '/css', :from => "assets/css"

  css :main, ["/css/foundation.css","/css/offcanvas.css","/css/app.css"]
  js :main, ["/js/jquery.js","/js/foundation.js","/js/jquery.offcanvas.js","/js/app.js"]

  js_compression  :jsmin    # :jsmin | :yui | :closure | :uglify
  css_compression :sass   # :simple | :sass | :yui | :sqwish
end

Then, in my layout.haml, I have: != css :main and != js :main. The problem is, though, whether I'm in development or production mode, the css and js helpers render HTML to load the actual files and not a stitched nor compressed version.

Anyone else had this happen or have ideas for me?

Thanks so much in advance!

Mark

[marks]

Now I'm able to get it to include just one js and one css file but the routes for those URLs respond with a blank document :(

[syntruth]

Having the same issue here. It works fine in :development but in :production, the app.css file is empty and the app.js file contains a single semicolon.

[j15e]

Looks like something that occurred to me that I fixed, could you try with latest version?

[j15e]

Could you also provide logs?

[gregjopa]

I'm experiencing the same problem. Everything works great in development but when I run in production the single js and css files are empty. I'm using sinatra-assetpack 0.1.5. I've ran heroku logs and I don't see any errors at all. My app is running on the Heroku Cedar stack. I'm not using the therubyracer-heroku gem since I've read that its not necessary anymore (https://devcenter.heroku.com/articles/rails3x-asset-pipeline-cedar#therubyracer). I'm using Twitter Bootstrap for my css framework and my assetpack configuration is very similar to this gist: https://gist.github.com/phillbaker/4652773

What other info/logs can I provide you to help troubleshoot this issue?

[j15e]

Are you using LESS too @marks?

The following app I made is working with less & assetpack on heroku, maybe you can have a look at it :

https://github.com/qcouvert/seaoo-web

[gregjopa]

@j15e thanks for your help. I compared your seaoo-web app w/ my code and the only thing I noticed that was different was the paths used for the css bootstrap import statements. I'm using Less.paths << File.join(PadrinoBootstrapDemo.root, '/assets/stylesheets') to shorten up my paths for the import statements. I tried using full paths in my css import statements instead of setting Less.paths but still get the same error when running in production.

I'm using Padrino w/ my app. I created a basic padrino app with the sinatra-assetpack and I'm able to reproduce this error. I uploaded this project to github here: https://github.com/gregjopa/padrino_bootstrap_demo

The app runs fine in development and loads all the bootstrap css files successfully. However, when its run in production the asset compilation fails with the following error:
[31m ERROR[0m -[33m17/Feb/2013 23:07:42[0mLess::Error - expected ')' got ',': /Users/grjopa/.rvm/gems/ruby-1.9.3-p286@padrino_bootstrap_demo/gems/less-2.2.2/lib/less/parser.rb:35:in `block (2 levels) in parse' at less.Parser.parser.parse (/Users/grjopa/.rvm/gems/ruby-1.9.3-p286@padrino_bootstrap_demo/gems/less-2.2.2/lib/less/js/lib/less/parser.js:343:24)

This definitely seems like a LESS issue. Any ideas on how I can resolve this?

[gregjopa]

This line of code css_compression :less is what was causing the error for me. I commented out this css_compression setting and my demo app runs fine in production. Also, it appears to still minify the css without this setting:

• http://padrino-bootstrap-demo.herokuapp.com/
• source: https://github.com/gregjopa/padrino_bootstrap_demo

I am still experiencing this "works in development but fails in production" problem with another padrino app. The difference between my working app and my broken app is my broken app does not have a folder named app. Instead, it was renamed to www which I think is causing my problem. Do you think renaming the Padrino app folder to something different would cause the siantra-assetpack to break? It doesn't seem like it should. I will try to isolate this problem in a new branch in my demo app.

[syntruth]

Sorry to get back with you much later!

I have found two issues that were causing me the issue above:

Using sinatra-assetpack (0.1.2)

1.) extra dots in the filename. jquery.validate.js <-- the version I was using didn't like this; I replaced extra dots with dashes and things worked again.

Ran into the issue again...and this time...

2.) had two files app/js/coffee/cwo.coffee and app/js/coffee/models/cwo.coffee -- this caused a error that was very hard for me to catch (due to my NTLMv2 auth setup. :( ) -- I stumbled upon it when syncing to a known good state and noticed the extra cwo.coffee file outside the models dir, which should not have been there. I nuked that file, restarted the production web process and boom, application.js contained all the data that was supposed to be there. In short: dupe file names, even on different paths, muck up the compilation. Sadly, I have no trace of where this is happening.

[alan-andrade]

Same problem here. It doesn't work in production. The files that are supposed to have all the assets compressed, are empty.

[syntruth]

Check the above two issues: extra dots in the file names and duplicate files in the app/js/* directories. Since fixing those in my local apps, I've had no issues at all. One of these evenings, I'll purposedly break on to get a trace or something for this post. (Just too busy to worry about it now that it work. :( )

[alan-andrade]

I'm not changing filenames just to make this work.

[inancgumus]

Unfortunately, same here. No clue found yet.

[alan-andrade]

So bad it just happens is production environment, just when you though it worked!

I ended up using jammit for sinatra. It's fairly simple and you have more control of where your assets get stored and stuff like that.

Also, you need to use some Padrino View helpers that might now work as expected if your using Sinatra helpers.

[j15e]

Where do you deploy and could you provide mode details? I can't see the common factor between theses issues yet

[j15e]

@gregjopa I have installed & run your demo padrino_bootstrap_demo without issues, seems to be related to your environement. What platform / ruby version are you using? I run on ruby-1.9.3-p392 on OSX with rvm

[inancgumus]

@alanandrade I also ended up using sprockets and yui-compressor directly instead of using sinatra-assetpack; this combo made it light-speed fast.

@j15e I run it with rackup -Eproduction but no hope.

[j15e]

Just FYI, I also use sprockets on some projects but I'd like to maintain & keep sinatra-assetpack as an alternative that is lightweight & very easy to use with sinatra.

[alan-andrade]

@j15e yeah, sinatra-assetpack seems like a good player for sinatra assets. Not very flexible in my opinion, but still, we can improve it! 👍

[j15e]

Hi everybody, any new development on this issue? Have any new version fixed the issue?

[alan-andrade]

We should pair sometime soon to fix it man. I think this gem is great.

[robconery]

I had this problem as well, and it turned out that asset-pack was unable to overwrite the destination file that existed on disk already. The reason it was there was because I was trying out the rake task and it built all my stuff and dropped it into the destination file ("/stylesheets/application.css").

It was empty in the beginning because I screwed some stuff up - but once I deleted the directories (the destination) all worked fine - even with the extra dots :).

[robconery]

OK - a further update, and I believe I have solved this. When you run a Sinatra/Padrino app in dev, the "root" of your app is ... well the root of your directory. So if you have an "/app" file, asset-pack will find it right where you specifiy: at "/app".

However, in production, when you push with Capistrano the root of your app (if you using Unicorn or Passenger) is "current/public", so when asset-pack tries to find your css or js files, it will be looking in "/current/public/css" as opposed to where you told it to look.

This happens, apparently, because :root is set to File.dirname(FILE) which, in production, is "current/public".

I verified this by creating symlinks in a "public/app" directory for "css" and "js". Then, magically, everything worked.

Hope this helps someone and, also, I hope it can be tracked and fixed (forking now)

[reicheltd]

sorry but I am giving up this gem. what a waste of time. I could list numerous examples of odd behaviour, especially in production. But I am too fed up now with this.

[j15e]

@reicheltd sprocket is rack compatible and I would say is the currently recommended assets solution for Sinatra & Padrino for any new project.

You should find many solutions if you look for sprockets + sinatra on internet.

https://github.com/sstephenson/sprockets

[Esop]

@j15e To be clear are you saying to use Sprockets instead of this gem now?

[j15e]

Yes

Le samedi 22 février 2014, Esop notifications@github.com a écrit :

@j15e https://github.com/j15e To be clear are you saying to use
Sprockets instead of this gem now?

Reply to this email directly or view it on GitHubhttps://github.com//issues/62#issuecomment-35810507
.

[stujo]

POSSIBLE FIX:

I had the same problem. In my case I was filtering requests based on the host name

This gem uses session = Rack::Test::Session.new(@assets.app) to access the resources before compressing them

If result.body is empty, you end up with some or all of the content missing

In my case I was enforcing a host name redirect and so result.body was empty

I worked around the issue by avoiding the redirect in the case the host name was 'example.org which is the case when the default (Rack::Test::DEFAULT_HOST)

This fixed the problem allowing the resources to be served.

I can imagine similar problems if you have resources behind authentication or other

sinatra-assetpack-0.3.3/lib/sinatra/assetpack/package.rb:106
def combined

Is the place to look

Happy New Year

[felixyz]

@stujo Could you provide more info about your solution? I ran into this issue, using a gem which depends on sinatra-assetpack in a Rack app which uses Rack::Auth::Basic. Any insights would be appreciated!