-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Conversation
…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'});
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? |
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. |
I'd be interested in this too; import interpolation sounds like a reasonable way to do it. |
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. |
It's often asked for (import interpolation) but difficult.. you have to use Definitely prefer it as a solution to this problem.
|
I plan to implement import interpolation in 1.4.0 so closing this so as not to muddy the waters |
...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.