Recompile imported .less files after modification about less-rails HOT 32 CLOSED

The problem is not fixed yet. For less-rails users, my advice is to use full paths in imports.

from less-rails.

I am too familiar with @metaskills penchant for requesting testcases with respect to any gems he's authored, so I will only say, I'm sorry I don't have one defined and published. However: This issue (and several related issues) is still present.
I have an application.css which imports a common.less file.
The common.less file imports several other files. (zones.less for example.)

No changes to zones.less show up, even after an application restart in development mode.
The only way to get changes from zones.less to be effective is to change the common.less file in some way.
Making _any_ change (even just adding a comment) in the common.less file (which is included via the manifest) causes changes from any imported files defined in that file to be effective.

This makes it very difficult to make changes in development mode.

from less-rails.

+1 no workaround working here. Only modifying application.css.less will trigger a recompile of imports.

from less-rails.

@tjwudi Try to do the following steps:

1. Close app
2. Reset cache use rake tmp:clear

If it doesn't works then try to update sprockets-rails gem use bundle update sprockets-rails command and retry steps above.

from less-rails.

I'm using less-rails 2.7.1 and still have the problem :/

from less-rails.

Hmm, less Rails could set that. Perhaps I should reopen the ticket?

from less-rails.

The config.env.less I suggested above probably does not make any difference, but I am having the following problem:

I have application.less, that includes a bunch of .less files from assets/stylesheets. There are some included files that get recompiled after I edit & save them, and for some included files I always get the cached version. If I rename the included file (and the @import statement), the file starts to behave as expected (save imported file, refresh stylesheet - changes are visible). But if I move the file back to its original name, it behaves as 'always cached' again.

Very strange. That's why I initially thought my config.less.env made any difference: before I was testing on a file that acted as cached, but after modifying the config I was testing on a file that was being recompiled anyway.

from less-rails.

I had the same issues with deep nested imports in the less files.
The change on some files wasn't triggering the recompile, the problem was with the way I was doing the import of the less files and their relatives path.

I was able to track the problem using debug statements in the less-rails template parser.

https://github.com/metaskills/less-rails/blob/master/lib/less/rails/import_processor.rb#L18-L22

The rescue statement is silencing all the file not found from sprockets and since he is watching the files needed for invalidation he is not aware of the depending files.

The less parser had no problem finding the files and compiling them on a fresh cache/first load.

If we can't remove the rescue block we should at least log the events to the console?

from less-rails.

Looking through the code it appears that when less-rails updates the context, it doesn't respect the curent directory depth, so that files imported from a file in a subdirectory depend on files as if the dependency was in the root directory. The fix should be to make sure the dependancies use the full path from the root directory.

from less-rails.

I was able to partially fix this in #64, but there is another error that I haven't been able to figure out.

from less-rails.

EXAMPLE:

/*
 * This is a manifest file that'll be compiled into application.css, which will include all the files
 * listed below.
 *
 //= require common
 //= require_self
*/

and then adding the following in common.less

@import "custom_bootstrap";
 //= depend_on zones.less
@import "zones";

I was temporarily fooled into believing that adding depend_on fixed the problem, but that only 'appeared' to work, because I was changing the common.less file, which always causes recompile of the import file. So ignore the depend_on clause shown above

from less-rails.

I found out that even in Sass, It never did implicit depends the way I thought it would have. For instnace. If I had a top level application.css manifest that required a foo/index and that mapped to a file called foo/index.scss which in turn that file did a set of @import "./bar"; Sass partials. The depend_on never worked in the partials I had to place them in the foo/index.scss to work.

from less-rails.

Yes, I actually don't think this is less-rails issue. I suspect it has more to do with how sprockets watches for changes. It is only registering the files that are directly referred to in the manifest. So therefor it isn't monitoring changes in any imported assets. I tried using the guard/listen gem and also just guard to detect changes and then update the file listed in the manifest using this ruby script:

less_files = Dir["app/assets/stylesheets/*.less"]
less_files.each do |less_file|
  lines = File.readlines(less_file)
  lines[0].match /\/\/ @refresh=(\d)/ do |m|
    puts " Refreshing less output for #{less_file}"
    lines[0] = "// @refresh=#{m.captures[0].to_i + 1}\n"
    File.open(less_file, 'w') {|f| f.write(lines.join()) }
  end

end

But predictably this ended up creating an infinite loop, since I was changing files that were being watched! I could fix it by not watching files that are directly included in the manifest. But haven't had time to write that script. I might look into the sprockets/less gem and see if I can figure out how it is storing it's watch list, and whether there is a way to get it to traverse the imports and watch them as well.

from less-rails.

@metaskills So this same issue is also an issue for SASS? Is it exactly identical, or is it a bit different?

from less-rails.

@cableray Exact same I think. Once you enter the realm of Sass/Less doing the imports, other imports or asset helpers in those imported files will never make their way to busting the top level Sass/Less that imported said files.

The best I was ever able to come up with was to make and test that less imported files themselves declared themselves as dependencies to the sprockets asset file that imported them. This is what ImportProcessor is for.

from less-rails.

Ok. Yeah, I think I get what you mean: SASS and LESS themselves don't register imports with the pipeline, that has to be done in another step (ImportProcessor). But once that is done, and the pipeline has the right dependency tree, it should trigger a recompile of the root node of the tree that contains the changed file. Correct?

from less-rails.

Bizarrely! sprockets has started recompiling my imports as of yesterday. Ill need to look at what has changed to see why this is.

Ashley Raiteri

e: [email protected]
*live phone +1.919.360.7050
gvoice: +1.919.725.7050
t: @ashr l: linkedin.com/in/ashleyraiteri
b: http://ashley.raiteri.net

On Sep 5, 2013, at 3:16 PM, Garrett [email protected] wrote:

Ok. Yeah, I think I get what you mean: SASS and LESS themselves don't register imports with the pipeline, that has to be done in another step. But once that is done, and the pipeline has the right dependency tree, it should trigger a recompile of the root node of the tree that contains the changed file. Correct?

—
Reply to this email directly or view it on GitHub.

from less-rails.

Cool, closing this out. Our behavior is the same for Sass.

BTW @ashrocket, your example above should have looked something like this right? If so, this should have worked for you.

//= depend_on zones.less
@import "custom_bootstrap";
@import "zones";

from less-rails.

I nailed the source of MY problem. Not sure how much this affects the other problems but here goes a description.
There is a test repo you use to verify my findings here:
https://github.com/ashrocket/lesscompiletest.git

Finding:
Setup application.css does not require tree, but instead requires a common importer.less file

importer.less imports the all_bootstrap as described in ReadMe (didn't test subfolders, but that's probably a seperate issue)
importer.less imports 3 files that can affect the path 0.0.0.0:3000/test

import1.less, test.less and import2.less

1. import1.less sets H1 color to @btnSuccessBackground
2. tests.less sets H1 color to @btnInfoBackground
3. import2.less sets H1 color to @btnWarningBackground

Expectation:

• Commenting out style in import2.less should cause H1 on 0.0.0.0:3000/test to be set to @btnInfoBackground
• Commenting out style in test.less should cause H1 on 0.0.0.0:3000/test to be set to @btnSuccessBackground

Results

• Begin: If you make no changes. The H1 element should be @btnWarningBackground.
• Comment out H1 style in import2.less, H1 becomes @btnInfoBackground as defined in tests.less
• Comment out H1 style in tests.less, H1 should be @btnSuccessBackground, but it remains @btnInfoBackground. No Less recompile has been performed.

1. Comment in the .triggerme class style in import2.less
2. A recomplile is performed and the previously made change to H1 style in tests.less is picked up, causing the H1 element to become @btnSuccessBackground as defined in import1.less
3. Comment back _in_ the H1 style in tests.less. It should cause the H1 element to become @btnInfoBackground. It has no effect and remains @btnSuccessBackground.
4. Comment out the .triggerme class stlye in import2.less
5. A recompile is performed and your change to tests.less is picked up, setting the H1 element color to @btnInfoBackground
6. Comment back _in_ the H1 style in import2.less and the color returns to @btnWarningBackground as originally set.

Conclusion Less files that are named the same as a controller, are not monitored for changes and do not trigger a sprockets/less recompile when changed!

from less-rails.

I'm done thinking about it for now. My workaround to this problem is to simply _not_ put stuff in a controller_name.less file and use specifically named and imported less files.

from less-rails.

This workaround works. Thanks @ashrocket.

from less-rails.

Glad to hear. Wish I knew why Sprockets/Rails is caching less files that are named for their controllers. If there is a setting that controls this, I don't know what it is.

from less-rails.

This works! Thanks @ashrocket

from less-rails.

@yeouchien s workaround to rename .less-Files to css.less (mentioned in #41) helped me to let less recompile assets when they change.

from less-rails.

I have less files with names different to controllers. Also I've tried to rename them to .css.less instead of .less. Also I've tried to include './' before the file name. Nothing fixes the problem. The workaround I'm using by now is to add/remove './' before the name in the @import statement, which is not stable at all. I don't understand why this is happening :(

from less-rails.

I've got the same problem, nothing besides modifying the file that has the @includes works

from less-rails.

+1 no workaround working. Cannot seem to get any changes to imported files to trigger application.css.less to recompile.

from less-rails.

Any update? +1 for no workaround working.

from less-rails.

Seems like this issue has been fixed in #88. Do you have this problem with latest version of less-rails?

from less-rails.

According to Gemfile, I am using less-rails (2.6.0).

from less-rails.

@maxd Thank your for your advise. I solved that by changing the importing .less files. If I encounter this problem again, I will use your solutions. Thanks again!

from less-rails.

I confirm the issue is fixed. I updated less-rails (bundle update less-rails) from 2.5.0 to 2.6.0, now editing non-root files trigger the recompile 👍

from less-rails.