Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Control or increase the depth that imported less files are watched to refresh cache #41

Closed
msaspence opened this issue Aug 23, 2012 · 18 comments
Labels

Comments

@msaspence
Copy link

I have three levels of @metaskills
It seems that less-rails is only watching the top two levels for changes before reparsing the files

@edmundask
Copy link

👍

@chengguangnan
Copy link

Hi @metaskills , if you need to see the issue in a test case here is how.

You can modify @import "frameworks/bootstrap/variables"; to @import "variables";, the test case will fail.

I found that if an import is using full path "twitter/bootstrap/variables", then changes will be watched. But if it's imported as "variables" in a file "twitter/bootstrap/bootstrap.less", then it's not been watched.

@yelvert
Copy link

yelvert commented Dec 5, 2012

+1

This has been plaguing me for a year.

@yelvert
Copy link

yelvert commented Dec 5, 2012

After looking through the other issues in this repo, it appears that this issue has been brought up several times, with several "fixes".
#3
#10
#13
#26
#27

There seems to be something fundamentally wrong with the way @imports are handled in less-rails that is keeping sprockets from detecting a stale asset when a change is made a few levels into the @import tree.

I'd be happy to take a stab at fixing it myself, if someone could push me in the right direction.

@metaskills
Copy link
Owner

Sorry no recommendations, but we do have a good test system and you could easily grep the code as well as the git history on import stuff and get some clues as to what we have done before. A tested patch that does not break existing functionality and other tests would surely be merged in.

@yelvert
Copy link

yelvert commented Dec 5, 2012

I'll take a look, and see what I can find. The problem is definitely that changes made more than 1 @import deep are not reflected on the next request.

@yelvert
Copy link

yelvert commented Dec 5, 2012

Also, it seems that if all of your @import statements are relative to the app/assets/stylesheets directory, rather than that files directory, then this "caching" issue goes away, and stale assets are expired correctly. Thus, a simple fix could be to convert all @import paths to be relative to app/assets/stylesheets before doing any of the actual @import stuff to them. Just a thought

@metaskills
Copy link
Owner

But assets could be in vendor/assets or any other gems asset path.

@metaskills
Copy link
Owner

Hence that is why any changes need to be tested with less-rails-bootstrap too.

@RyanScottLewis
Copy link

When using the following setup:

stylesheets/application.css.less

//= require_self

@import 'projects';

stylesheets/projects.less

@import 'projects/index';
@import 'projects/show';

Editing stylesheets/projects/index.less or stylesheets/projects/show.less will not trigger a recompile.


However, removing stylesheets/projects.less and changing stylesheets/application.css.less to the following:

//= require_self

@import 'projects/index';
@import 'projects/show';

Will trigger a recompile.

Is this really an issue? I would say not. How is Sprockets supposed to follow all of the import declarations to determine when to recompile?

Just something one has to remember when importing LESS files. ✌️

@edmundask
Copy link

I have found somewhat a dirty workaround for this. You can actually use Sprocket's depend_on in your manifest file to add files to the tracking list. May get a bit redundant if you have a lot of imports, though, since, as far as I know, you can only give paths to files for depend_on, not directories, which is quite unfortunate.

@ph
Copy link

ph commented Mar 20, 2013

I am sorry for cross posting this, but this seem related to #46 (comment)

@felipero
Copy link

+1 to fix this

@metaskills
Copy link
Owner

Closing this issue, our behavior is the exact same as Sass and it is why depend_on exists. Note, I have found that you can not use depend_on if the file is imported. You have to use it at the top level .css.less file one level lower down. This is exactly what I found too in Sass.

@yeouchien
Copy link

I have discovered two workaround for this issue.

First workaround: rename all .less to .css.less
stylesheets/application.css.less

/*
 *= require project/index.css
*/

stylesheets/project/index.css.less

@import "project/calendar.css";
@import "project/autocomplete.css";

stylesheets/project/calendar.css.less || stylesheets/project/autocomplete.css.less


Second (dirty) workaround: put all less files in same directory.
stylesheets/application.css

/*
 *= require index
*/

stylesheets/index.less

@import "calendar";
@import "autocomplete";

stylesheets/calendar.less || stylesheets/autocomplete.less

Sass-rails doesn't seem to have this issue. I have tried to have 4 level of @import in sass-rails and it did recompile every time a file is changed.

@rstacruz
Copy link

The first workaround isn't a very good solution. I've found that the @import "x/y.css"; are left alone and not interpreted by Less, and they'll be interpreted by the browser as true @import directives.

@blakeperdue
Copy link

@metaskills can you give a bit more info about this statement? I'm not following what you're saying here:

Note, I have found that you can not use depend_on if the file is imported. You have to use it at the top level .css.less file one level lower down. This is exactly what I found too in Sass.

I'm not sure if you're saying you can't have depend_on and also import a LESS file in your application.css.less file? I'm also confused about using it "at the top level .css.less file one level lower down" ... is this saying use a .css.less file in a subfolder under app/assets/stylesheets in order to have depends_on work?

@metaskills
Copy link
Owner

My only advice with the time I have is to recommend that someone dive deep into sass-rails and their Importer class which is used in their template handler. They do a good job at processing imports and calling depend_on for the scope/context for all import files automatically. I tried to accomplish the same thing with the import_processor.rb but it may be time for someone to level it up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests