Skip to content

load_path issue? when changing environment to staging on 3-1-stable #39

Closed
tarikjn opened this Issue Sep 2, 2011 · 16 comments

6 participants

@tarikjn
tarikjn commented Sep 2, 2011

Hi,

I have an issue which I have been stuck on for now 2 days and seem to be associated with sass-rails and Rails 3.1.0 final (and rc8 before). I am using the latest snapshot from the 3-1-stable branch.

In my .css.scss files, I do @import "global" to include global.css.scss which has my mixins and vars.

When RACK_ENV and RAILS_ENV = development, everything works fine. As soon as I run with RACK_ENV and RAILS_ENV = staging, pre-compilation fails:

Error compiling CSS asset

Sass::SyntaxError: File to import not found or unreadable: global.
Load path: /Users/tarik/Documents/mojo/app/mojo
   (in /Users/tarik/Documents/mojo/app/mojo/app/assets/stylesheets/browser_alert.css.scss

  /Users/tarik/Documents/mojo/app/mojo/app/assets/stylesheets/browser_alert.css.scss:1

I noticed that the load path doesn't include the stylesheet directory, but why would this change when the environment is changed to staging? I have tried using monkey patches used to inject the load_path but I then stumble upon a new compilation issue (syntax issue near with /* lin without further indications).

This is truly driving me crazy... I've tried RAILS_GROUPS=assets rake assets:clean tmp:clear no succes, pre-compilation in the command line gives:

Macintosh-7:mojo tarik$ RAILS_GROUPS=assets bundle exec rake assets:precompile --trace
** Invoke assets:precompile (first_time)
** Execute assets:precompile
rake aborted!
Invalid CSS after "/* lin": expected identifier, was "/"
  (in /Users/tarik/Documents/mojo/app/mojo/app/assets/stylesheets/application.css)

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

but running without environment set (default is development) or setting it explicitly to development and everything is fine in the browser.

It gets even better changing the environment to production make things works (staging and production environment setting around in the application are all identical). Then changing the environment back to staging again works! This is because for some reason, in production, the compiled assets land in /public/assets (folder gets created) and then the staging reuse that. When I clean it up, I am back to the issue.

I have an identical issue on Heroku cedar (where my staging environment was supposed to be in the first place), but the above trick doesn't even work, /public being non-writable. Somehow the production environment on Heroku correctly write the assets in /tmp -- and clear them when restarting the app with the env set to staging.

Thanks for your help/hints... To me this has to be an inconsistency with rails/sass-rails, but at this point my brain is foggy and hurting, so I apologize in advance if it turns out I am not posting this issue in the right place.

@tarikjn
tarikjn commented Sep 2, 2011

update: I am able to reproduce the issue on a clean rails 3.1.0 app

The steps to reproduce the issues are:

(1) create a minimal rails 3.1.0 app, create a dumb scaffold, migrate
(2) have one or more of the .css.scss scaffold files @import "globals"; create corresponding empty file globals.css.scss in same dir
(3) cp config/environments/production.rb config/environments/staging.rb, fix config/database.yml for staging
(4) run rails server it works
(5) run rails server -e staging it asks for assets to be precompiled, run bundle exec rake assets:precompile (works), now run rails server -e staging again, it crashes:

Error compiling CSS asset

Sass::SyntaxError: File to import not found or unreadable: globals.
Load path: /Users/tarik/testsass
   (in /Users/tarik/testsass/app/mojo/app/assets/stylesheets/scaffolds.css.scss

  /Users/tarik/testsass/app/mojo/app/assets/stylesheets/scaffolds.css.scss:1

I have created a repository where I pushed the test app to reproduce the issue: https://github.com/tarikjn/sass-issue-demonstration

@nhocki
nhocki commented Sep 3, 2011

I'm also having this issue. It was working fine and suddenly stopped working. Any help?

@nhocki
nhocki commented Sep 3, 2011

@tarikjn try removing the gem versions from the Gemfile, it worked for me. I honestly don't know why, but that was the fix we had.

@guilleiguaran
Ruby on Rails member

@tarikjn, two things:

  1. You must run the precompile task using the environment bundle exec rake assets:precompile RAILS_ENV=staging

  2. You can enable config.serve_static_assets = true in staging.rb since you are testing in your local machine (in your server precompiled assets must be served by Apache/nginx)

@nhocki
nhocki commented Sep 3, 2011
@tarikjn
tarikjn commented Sep 5, 2011

@guilleiguaran I got to the bottom of the issue:

  • running those command made things work on my sample application :)
  • but not on my actual project, running bundle exec rake assets:precompile RAILS_ENV=development would work but bundle exec rake assets:precompile RAILS_ENV=staging would issue:
rake aborted!
Invalid CSS after "/* lin": expected identifier, was "/"
  (in /Users/tarik/testsass/app/assets/stylesheets/application.css)

Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

Thinking a unicode trick I started a step by step barbarian test by removing half of the files, then restoring files by files 1 by 1 and same for the lines in the file once I found which file it was (no useful debug info, even with --trace). Turns out:

/*
// non-visible
.line-half {
    position: absolute;
    width: 0;
    left: $ds * 2;
    top: 2px;
    height: 10px;
    border-left: 1px dotted gray;
}
*/

...was causing the issue, ie. a comment inside an other comment. The weird thing is that this works using RAILS_ENV=development but not RAILS_ENV=production or RAILS_ENV=staging. So there must still be a bug somewhere in the library...

This fixed the issue on my machine, but for Heroku, I still had to make sure to have config.assets.compress = true or I would still have the path issue. Also I had to comment config.assets.compile = false as this would cause an issue with including a browser support file I kept separate for IE browsers <= IE8.

@nhocki your suggestion didn't fix the issues for me, you must have run into something different?

@guilleiguaran
Ruby on Rails member

@tarikjn, looks like the problem is being caused by the Sass compressor. (compressor is off for development, this is the difference between development and staging/production environments)

@tarikjn
tarikjn commented Sep 5, 2011

@guilleiguaran sounds like it would make sense... although I am surprised to not find it in the sass bug tracker. Running out of time to do more research tonight but thank you for pointing me in the right direction.

@guilleiguaran
Ruby on Rails member

@tarikjn, as workaround you can try with the other compressor supported by Rails asset pipeline at the moment:

1- Add YUI compressor to your Gemfile:

gem 'yui-compressor'

2- Set YUI as the default compressor in config/environments/production.rb (or staging.rb):

config.assets.css_compressor = :yui

To use YUI you must have Java installed (this must be ok in Heroku).

Let me know if this works for you.

@chriseppstein

guys. I'm having a hard time sorting out the current state of this issue. Please update with current status. I do NOT think there is a parsing issue in sass regarding comments.

@akshayrawat

I have the same problem. Using yui compressor doesn't make a difference.

@akshayrawat

I found what my issue was. Part of the problem is that assets:precompile doesn't report the exact line no. where the compilation fails. It always reports like below, even when the problem (as in my case) maybe a stylesheet in vendor/assets

Invalid CSS after "/* lin": expected identifier, was "/"
  (in app/assets/stylesheets/application.css)

The Aristo query theme hosted on the Wijmo CDN has a potential syntax problem(?) (comment tag inside another comment)

.ui-slider .ui-slider-handle
{
    /*
    background: #85b2cb linear-gradient(top, rgba(255,255,255,0.8), rgba(255,255,255,0));
    background: #85b2cb -webkit-gradient(linear, left top, left bottom, from(rgba(255,255,255,0.8)), to(rgba(255,255,255,0)));
    background: #85b2cb -moz-linear-gradient(top, rgba(255,255,255,0.8), rgba(255,255,255,0)); /*   filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#DDFFFFFF, endColorstr=#00FFFFFF);     -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#DDFFFFFF, endColorstr=#00FFFFFF)"; */
*/
}

Notice the nested comment on the last line. I'm not sure if such nesting is permitted.. Once I removed the nesting, everything ran fine. Better error reporting by the assets:precompile task would greatly help.

@guilleiguaran
Ruby on Rails member

@akshayrawat actually assets:precompile don't print the errors, the errors are printed in Sprockets (this do the compiling and compression), but I agree, probably Sprockets can have better error reporting

@chriseppstein

Comments cannot be nested within each other. The error message is the best we can provide in this situation.

@nhocki
nhocki commented Sep 26, 2011

I think I know what the problem is now. If you have the assets group in your Gemfile and don't have the new Bundler require statement in config/application.rb it will fail.

You'll need to change the bundler require statement to this:

if defined?(Bundler)
  # If you precompile assets before deploying to production, use this line
  Bundler.require *Rails.groups(:assets => %w(development test))
  # If you want your assets lazily compiled in production, use this line
  # Bundler.require(:default, :assets, Rails.env)
end
@dougfarre

What is the solution here? Adding amending the config/application.rb didn't work for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.