Giter Club home page Giter Club logo

Comments (18)

yelvert avatar yelvert commented on July 25, 2024 1

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.

from less-rails.

edmundask avatar edmundask commented on July 25, 2024

👍

from less-rails.

chengguangnan avatar chengguangnan commented on July 25, 2024

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.

from less-rails.

yelvert avatar yelvert commented on July 25, 2024

+1

This has been plaguing me for a year.

from less-rails.

metaskills avatar metaskills commented on July 25, 2024

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.

from less-rails.

yelvert avatar yelvert commented on July 25, 2024

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.

from less-rails.

yelvert avatar yelvert commented on July 25, 2024

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

from less-rails.

metaskills avatar metaskills commented on July 25, 2024

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

from less-rails.

metaskills avatar metaskills commented on July 25, 2024

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

from less-rails.

RyanScottLewis avatar RyanScottLewis commented on July 25, 2024

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. ✌️

from less-rails.

edmundask avatar edmundask commented on July 25, 2024

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.

from less-rails.

ph avatar ph commented on July 25, 2024

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

from less-rails.

felipero avatar felipero commented on July 25, 2024

+1 to fix this

from less-rails.

metaskills avatar metaskills commented on July 25, 2024

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.

from less-rails.

yeouchien avatar yeouchien commented on July 25, 2024

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.

from less-rails.

rstacruz avatar rstacruz commented on July 25, 2024

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.

from less-rails.

blakeperdue avatar blakeperdue commented on July 25, 2024

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

from less-rails.

metaskills avatar metaskills commented on July 25, 2024

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.

from less-rails.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.