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

Allow version numbering of @imported less files so as to enabled browser cache busting when versions change. #1060

Closed
wants to merge 1 commit into from

Conversation

phuff
Copy link

@phuff phuff commented Dec 5, 2012

...oaded by the browser so that you can bust the browser cache with a version number. Use like so: new(less.Parser)({suffix: '?version=12345'});

We're using less.js at Ning to recompile individual social networks' css when network owners change style paramerters. This makes it so they can see a live update of what the changes to their color scheme, etc. will look like. For this purpose, we want a browser to cache the less files so that it's speedy to compile something with a lot of imports. But we also want to be able to bust that cache when we change the less styles so they don't get an old version of the less to customize. So we added in this suffix parameter to less.js to let us do that. Now we can still cache @import files on the users' browser, but bust the cache by updating the suffix when we make changes.

…n loaded by the browser so that you can bust the browser cache with a version number. Use like so: new(less.Parser)({suffix: '?version=12345'});
@lukeapage
Copy link
Member

I'm not sure on its use outside your use-case.

what server-side back-end do you have?

for me a better approach would be to have non-cached less files that can be accessed whilst a user is changing parameters and then a compiled css that is generated server-side based on updated parameters.. what do you think?

@phuff
Copy link
Author

phuff commented Dec 13, 2012

Ah sorry. Let me be more specific. The approach you're suggesting is what we already have, essentially.

Our live preview lets the user tweak less variables. After each variable is tweaked, we recompile the less to update the page using lessjs. The problem is our less is very modular; as a result it has a lot of @imports. This means that lessjs makes a lot of calls to load the @imported less each time a user changes a variable. We actually want the browser to cache the less most of the time, because it doesn't change very often. This makes it so that the browser can just give lessjs the cached version of the @imported less files when the user compiles which speeds up compilation quite nicely.

So under normal circumstances, lessjs is behaving just as we would want: it uses a regular browser GET request to load the @imports and therefore they get cached in the browser.

The problem that this patch solves comes when we (Ning) make occasional changes to the less. Now we need to break the browser's cache of the less files that the user had previously loaded there. The typical way to do that is to just add a version parameter to the file that the browser is requesting via GET, and then to update that version parameter so that the browser does a new GET instead of relying on its cache. Unfortunately you can't really do that within the less itself (I tried something like @import "filename.less@{versionParam}" and lessjs doesn't interpolate the variables there). So, I added this patch which lets you specify a version to add to each imported file, since I figured that we can't be the only people with this problem (where this problem == "wanting to rely on the browser cache to speed up compilation of less files with @imports, but wanting to be able to bust that cache when necessary").

I suppose the other way to solve this problem would be to allow string interpolation inside of @import's but I assumed (perhaps wrongly) that this was disallowed for security reasons or something.

@Synchro
Copy link
Member

Synchro commented Dec 13, 2012

I'd be interested in this too; import interpolation sounds like a reasonable way to do it.

@phuff
Copy link
Author

phuff commented Dec 13, 2012

Yeah, I guess the reason why I didn't try and implement import interpolation was that: a. this was quicker :) and b. that it seems like a change to the language, which probably should be taken a little more seriously. We're using lessphp on the backend to compile, mostly just because we're a php shop and I can't remember what it did when I added the input interpolation. Anyway, in any case, we're using the above patch right now, but could easily switch to import interpolation if that's more amenable to people.

@lukeapage
Copy link
Member

It's often asked for (import interpolation) but difficult.. you have to use
the variables currently available to evaluate a import that might further
change variables and that kind of multiple passes is not compatible with
how less is designed at the moment. I'd like to do it, but after 1.4.0.

Definitely prefer it as a solution to this problem.
On Dec 13, 2012 6:29 PM, "Paul Huff" [email protected] wrote:

Yeah, I guess the reason why I didn't try and implement import
interpolation was that: a. this was quicker :) and b. that it seems like a
change to the language, which probably should be taken a little more
seriously. We're using lessphp on the backend to compile, mostly just
because we're a php shop and I can't remember what it did when I added the
input interpolation. Anyway, in any case, we're using the above patch right
now, but could easily switch to import interpolation if that's more
amenable to people.


Reply to this email directly or view it on GitHubhttps://github.com//pull/1060#issuecomment-11346505.

@lukeapage
Copy link
Member

I plan to implement import interpolation in 1.4.0 so closing this so as not to muddy the waters

@lukeapage lukeapage closed this Feb 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants