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

[msaspence]

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]

:+1:

[chengguangnan]

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]

+1

This has been plaguing me for a year.

[yelvert]

After looking through the other issues in this repo, it appears that this issue has been brought up several times, with several "fixes". https://github.com/metaskills/less-rails/issues/3 https://github.com/metaskills/less-rails/issues/10 https://github.com/metaskills/less-rails/issues/13 https://github.com/metaskills/less-rails/issues/26 https://github.com/metaskills/less-rails/issues/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]

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]

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]

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]

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

[metaskills]

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

[RyanScottLewis]

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. :v:

[edmundask]

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]

I am sorry for cross posting this, but this seem related to https://github.com/metaskills/less-rails/issues/46#issuecomment-15182653

[felipero]

+1 to fix this

[metaskills]

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]

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]

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]

@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]

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.