usemin, rev, less, source maps and IE8 selector count support - css

This is a source of concern and hard to solve whilst retaining the requirements.
Using usemin via grunt tasks to optimise a build of a complex and rather large application. The problem right now is that IE8 and IE9 are dropping CSS rule declarations from a single file being built on account of the ambiguous 4095 max rules limit.
currently, it works like so:
less builds one big file main-min.css in dist
source map added main-min.css.map
usemin process with rev to main-min.<hash>.css, main-min.<hash>.css.map
going forward, it needs:
less builds one big file main-min.css in dist
something like https://github.com/project-collins/grunt-csssplit converts to main-min-part1.css and main-min-part2.css (and so on). currently does not return names of new files, no support for source maps - but this is easy to patch and add or read from the FS
usemin to pickup the new split styles eg, from an assetDir and include all separately (not concatenated), which seems lacking in examples/workflow that try to create single files exclusively.
parts now rev'd
source maps? (acceptable to lose this)
any ideas / examples of such a setup appreciated. or alternative approaches.

If I understand your requirement correctly, this is the brief idea to solve your problem:
Steps:
1. Defined a pattern in your index.html. For instance:
<!--USE_MIN_BLOCKS-->
<!--END_BLOCK-->
2. Make a new replace task to replace above block with new usemin blocks dynamically (based on generated files of grunt-csssplit).
For instance:
replace: {
usemin: [{
match: /<!--CSS_USEMIN_BLOCKS-->[\S\s]+<!--END_BLOCK-->/i, replacement: function() {
//put your link tag here
linkTag += ' <!-- build:css css/' + cssFile + ' -->\n';
linkTag += ' <link rel="stylesheet" href="css/' + cssFile + '">\n';
linkTag += ' <!-- endbuild -->\n';
}
}]
}
3. Run the replace:usemin task before usemin task.

Related

Django Static Files Won't Reload On Firefox [duplicate]

I have noticed that some browsers (in particular, Firefox and Opera) are very zealous in using cached copies of .css and .js files, even between browser sessions. This leads to a problem when you update one of these files, but the user's browser keeps on using the cached copy.
What is the most elegant way of forcing the user's browser to reload the file when it has changed?
Ideally, the solution would not force the browser to reload the file on every visit to the page.
I have found John Millikin's and da5id's suggestion to be useful. It turns out there is a term for this: auto-versioning.
I have posted a new answer below which is a combination of my original solution and John's suggestion.
Another idea that was suggested by SCdF would be to append a bogus query string to the file. (Some Python code, to automatically use the timestamp as a bogus query string, was submitted by pi..)
However, there is some discussion as to whether or not the browser would cache a file with a query string. (Remember, we want the browser to cache the file and use it on future visits. We only want it to fetch the file again when it has changed.)
This solution is written in PHP, but it should be easily adapted to other languages.
The original .htaccess regex can cause problems with files like json-1.3.js. The solution is to only rewrite if there are exactly 10 digits at the end. (Because 10 digits covers all timestamps from 9/9/2001 to 11/20/2286.)
First, we use the following rewrite rule in .htaccess:
RewriteEngine on
RewriteRule ^(.*)\.[\d]{10}\.(css|js)$ $1.$2 [L]
Now, we write the following PHP function:
/**
* Given a file, i.e. /css/base.css, replaces it with a string containing the
* file's mtime, i.e. /css/base.1221534296.css.
*
* #param $file The file to be loaded. Must be an absolute path (i.e.
* starting with slash).
*/
function auto_version($file)
{
if(strpos($file, '/') !== 0 || !file_exists($_SERVER['DOCUMENT_ROOT'] . $file))
return $file;
$mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $file);
return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $file);
}
Now, wherever you include your CSS, change it from this:
<link rel="stylesheet" href="/css/base.css" type="text/css" />
To this:
<link rel="stylesheet" href="<?php echo auto_version('/css/base.css'); ?>" type="text/css" />
This way, you never have to modify the link tag again, and the user will always see the latest CSS. The browser will be able to cache the CSS file, but when you make any changes to your CSS the browser will see this as a new URL, so it won't use the cached copy.
This can also work with images, favicons, and JavaScript. Basically anything that is not dynamically generated.
Simple Client-side Technique
In general, caching is good... So there are a couple of techniques, depending on whether you're fixing the problem for yourself as you develop a website, or whether you're trying to control cache in a production environment.
General visitors to your website won't have the same experience that you're having when you're developing the site. Since the average visitor comes to the site less frequently (maybe only a few times each month, unless you're a Google or hi5 Networks), then they are less likely to have your files in cache, and that may be enough.
If you want to force a new version into the browser, you can always add a query string to the request, and bump up the version number when you make major changes:
<script src="/myJavascript.js?version=4"></script>
This will ensure that everyone gets the new file. It works because the browser looks at the URL of the file to determine whether it has a copy in cache. If your server isn't set up to do anything with the query string, it will be ignored, but the name will look like a new file to the browser.
On the other hand, if you're developing a website, you don't want to change the version number every time you save a change to your development version. That would be tedious.
So while you're developing your site, a good trick would be to automatically generate a query string parameter:
<!-- Development version: -->
<script>document.write('<script src="/myJavascript.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>
Adding a query string to the request is a good way to version a resource, but for a simple website this may be unnecessary. And remember, caching is a good thing.
It's also worth noting that the browser isn't necessarily stingy about keeping files in cache. Browsers have policies for this sort of thing, and they are usually playing by the rules laid down in the HTTP specification. When a browser makes a request to a server, part of the response is an Expires header... a date which tells the browser how long it should be kept in cache. The next time the browser comes across a request for the same file, it sees that it has a copy in cache and looks to the Expires date to decide whether it should be used.
So believe it or not, it's actually your server that is making that browser cache so persistent. You could adjust your server settings and change the Expires headers, but the little technique I've written above is probably a much simpler way for you to go about it. Since caching is good, you usually want to set that date far into the future (a "Far-future Expires Header"), and use the technique described above to force a change.
If you're interested in more information on HTTP or how these requests are made, a good book is "High Performance Web Sites" by Steve Souders. It's a very good introduction to the subject.
Google's mod_pagespeed plugin for Apache will do auto-versioning for you. It's really slick.
It parses HTML on its way out of the webserver (works with PHP, Ruby on Rails, Python, static HTML -- anything) and rewrites links to CSS, JavaScript, image files so they include an id code. It serves up the files at the modified URLs with a very long cache control on them. When the files change, it automatically changes the URLs so the browser has to re-fetch them. It basically just works, without any changes to your code. It'll even minify your code on the way out too.
Instead of changing the version manually, I would recommend you use an MD5 hash of the actual CSS file.
So your URL would be something like
http://mysite.com/css/[md5_hash_here]/style.css
You could still use the rewrite rule to strip out the hash, but the advantage is that now you can set your cache policy to "cache forever", since if the URL is the same, that means that the file is unchanged.
You can then write a simple shell script that would compute the hash of the file and update your tag (you'd probably want to move it to a separate file for inclusion).
Simply run that script every time CSS changes and you're good. The browser will ONLY reload your files when they are altered. If you make an edit and then undo it, there's no pain in figuring out which version you need to return to in order for your visitors not to re-download.
I am not sure why you guys/gals are taking so much pain to implement this solution.
All you need to do if get the file's modified timestamp and append it as a querystring to the file.
In PHP I would do it as:
<link href="mycss.css?v=<?= filemtime('mycss.css') ?>" rel="stylesheet">
filemtime() is a PHP function that returns the file modified timestamp.
You can just put ?foo=1234 at the end of your CSS / JavaScript import, changing 1234 to be whatever you like. Have a look at the Stack Overflow HTML source for an example.
The idea there being that the ? parameters are discarded / ignored on the request anyway and you can change that number when you roll out a new version.
Note: There is some argument with regard to exactly how this affects caching. I believe the general gist of it is that GET requests, with or without parameters should be cachable, so the above solution should work.
However, it is down to both the web server to decide if it wants to adhere to that part of the spec and the browser the user uses, as it can just go right ahead and ask for a fresh version anyway.
I've heard this called "auto versioning". The most common method is to include the static file's modification time somewhere in the URL, and strip it out using rewrite handlers or URL configurations:
See also:
Automatic asset versioning in Django
Automatically Version Your CSS and JavaScript Files
The 30 or so existing answers are great advice for a circa 2008 website. However, when it comes to a modern, single-page application (SPA), it might be time to rethink some fundamental assumptions… specifically the idea that it is desirable for the web server to serve only the single, most recent version of a file.
Imagine you're a user that has version M of a SPA loaded into your browser:
Your CD pipeline deploys the new version N of the application onto the server
You navigate within the SPA, which sends an XMLHttpRequest (XHR) to the server to get /some.template
(Your browser hasn't refreshed the page, so you're still running version M)
The server responds with the contents of /some.template — do you want it to return version M or N of the template?
If the format of /some.template changed between versions M and N (or the file was renamed or whatever) you probably don't want version N of the template sent to the browser that's running the old version M of the parser.†
Web applications run into this issue when two conditions are met:
Resources are requested asynchronously some time after the initial page load
The application logic assumes things (that may change in future versions) about resource content
Once your application needs to serve up multiple versions in parallel, solving caching and "reloading" becomes trivial:
Install all site files into versioned directories: /v<release_tag_1>/…files…, /v<release_tag_2>/…files…
Set HTTP headers to let browsers cache files forever
(Or better yet, put everything in a CDN)
Update all <script> and <link> tags, etc. to point to that file in one of the versioned directories
That last step sounds tricky, as it could require calling a URL builder for every URL in your server-side or client-side code. Or you could just make clever use of the <base> tag and change the current version in one place.
† One way around this is to be aggressive about forcing the browser to reload everything when a new version is released. But for the sake of letting any in-progress operations to complete, it may still be easiest to support at least two versions in parallel: v-current and v-previous.
In Laravel (PHP) we can do it in the following clear and elegant way (using file modification timestamp):
<script src="{{ asset('/js/your.js?v='.filemtime('js/your.js')) }}"></script>
And similar for CSS
<link rel="stylesheet" href="{{asset('css/your.css?v='.filemtime('css/your.css'))}}">
Example HTML output (filemtime return time as as a Unix timestamp)
<link rel="stylesheet" href="assets/css/your.css?v=1577772366">
Don’t use foo.css?version=1!
Browsers aren't supposed to cache URLs with GET variables. According to http://www.thinkvitamin.com/features/webapps/serving-javascript-fast, though Internet Explorer and Firefox ignore this, Opera and Safari don't! Instead, use foo.v1234.css, and use rewrite rules to strip out the version number.
Here is a pure JavaScript solution
(function(){
// Match this timestamp with the release of your code
var lastVersioning = Date.UTC(2014, 11, 20, 2, 15, 10);
var lastCacheDateTime = localStorage.getItem('lastCacheDatetime');
if(lastCacheDateTime){
if(lastVersioning > lastCacheDateTime){
var reload = true;
}
}
localStorage.setItem('lastCacheDatetime', Date.now());
if(reload){
location.reload(true);
}
})();
The above will look for the last time the user visited your site. If the last visit was before you released new code, it uses location.reload(true) to force page refresh from server.
I usually have this as the very first script within the <head> so it's evaluated before any other content loads. If a reload needs to occurs, it's hardly noticeable to the user.
I am using local storage to store the last visit timestamp on the browser, but you can add cookies to the mix if you're looking to support older versions of IE.
The RewriteRule needs a small update for JavaScript or CSS files that contain a dot notation versioning at the end. E.g., json-1.3.js.
I added a dot negation class [^.] to the regex, so .number. is ignored.
RewriteRule ^(.*)\.[^.][\d]+\.(css|js)$ $1.$2 [L]
Interesting post. Having read all the answers here combined with the fact that I have never had any problems with "bogus" query strings (which I am unsure why everyone is so reluctant to use this) I guess the solution (which removes the need for Apache rewrite rules as in the accepted answer) is to compute a short hash of the CSS file contents (instead of the file datetime) as a bogus querystring.
This would result in the following:
<link rel="stylesheet" href="/css/base.css?[hash-here]" type="text/css" />
Of course, the datetime solutions also get the job done in the case of editing a CSS file, but I think it is about the CSS file content and not about the file datetime, so why get these mixed up?
For ASP.NET 4.5 and greater you can use script bundling.
The request http://localhost/MvcBM_time/bundles/AllMyScripts?v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81 is for the bundle AllMyScripts and contains a query string pair v=r0sLDicvP58AIXN_mc3QdyVvVj5euZNzdsa2N1PKvb81. The query string v has a value token that is a unique identifier used for caching. As long as the bundle doesn't change, the ASP.NET application will request the AllMyScripts bundle using this token. If any file in the bundle changes, the ASP.NET optimization framework will generate a new token, guaranteeing that browser requests for the bundle will get the latest bundle.
There are other benefits to bundling, including increased performance on first-time page loads with minification.
For my development, I find that Chrome has a great solution.
https://superuser.com/a/512833
With developer tools open, simply long click the refresh button and let go once you hover over "Empty Cache and Hard Reload".
This is my best friend, and is a super lightweight way to get what you want!
Thanks to Kip for his perfect solution!
I extended it to use it as an Zend_view_Helper. Because my client run his page on a virtual host I also extended it for that.
/**
* Extend filepath with timestamp to force browser to
* automatically refresh them if they are updated
*
* This is based on Kip's version, but now
* also works on virtual hosts
* #link http://stackoverflow.com/questions/118884/what-is-an-elegant-way-to-force-browsers-to-reload-cached-css-js-files
*
* Usage:
* - extend your .htaccess file with
* # Route for My_View_Helper_AutoRefreshRewriter
* # which extends files with there timestamp so if these
* # are updated a automatic refresh should occur
* # RewriteRule ^(.*)\.[^.][\d]+\.(css|js)$ $1.$2 [L]
* - then use it in your view script like
* $this->headLink()->appendStylesheet( $this->autoRefreshRewriter($this->cssPath . 'default.css'));
*
*/
class My_View_Helper_AutoRefreshRewriter extends Zend_View_Helper_Abstract {
public function autoRefreshRewriter($filePath) {
if (strpos($filePath, '/') !== 0) {
// Path has no leading '/'
return $filePath;
} elseif (file_exists($_SERVER['DOCUMENT_ROOT'] . $filePath)) {
// File exists under normal path
// so build path based on this
$mtime = filemtime($_SERVER['DOCUMENT_ROOT'] . $filePath);
return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $filePath);
} else {
// Fetch directory of index.php file (file from all others are included)
// and get only the directory
$indexFilePath = dirname(current(get_included_files()));
// Check if file exist relativ to index file
if (file_exists($indexFilePath . $filePath)) {
// Get timestamp based on this relativ path
$mtime = filemtime($indexFilePath . $filePath);
// Write generated timestamp to path
// but use old path not the relativ one
return preg_replace('{\\.([^./]+)$}', ".$mtime.\$1", $filePath);
} else {
return $filePath;
}
}
}
}
I have not found the client-side DOM approach creating the script node (or CSS) element dynamically:
<script>
var node = document.createElement("script");
node.type = "text/javascript";
node.src = 'test.js?' + Math.floor(Math.random()*999999999);
document.getElementsByTagName("head")[0].appendChild(node);
</script>
Say you have a file available at:
/styles/screen.css
You can either append a query parameter with version information onto the URI, e.g.:
/styles/screen.css?v=1234
Or you can prepend version information, e.g.:
/v/1234/styles/screen.css
IMHO, the second method is better for CSS files, because they can refer to images using relative URLs which means that if you specify a background-image like so:
body {
background-image: url('images/happy.gif');
}
Its URL will effectively be:
/v/1234/styles/images/happy.gif
This means that if you update the version number used, the server will treat this as a new resource and not use a cached version. If you base your version number on the Subversion, CVS, etc. revision this means that changes to images referenced in CSS files will be noticed. That isn't guaranteed with the first scheme, i.e. the URL images/happy.gif relative to /styles/screen.css?v=1235 is /styles/images/happy.gif which doesn't contain any version information.
I have implemented a caching solution using this technique with Java servlets and simply handle requests to /v/* with a servlet that delegates to the underlying resource (i.e. /styles/screen.css). In development mode I set caching headers that tell the client to always check the freshness of the resource with the server (this typically results in a 304 if you delegate to Tomcat's DefaultServlet and the .css, .js, etc. file hasn't changed) while in deployment mode I set headers that say "cache forever".
You could simply add some random number with the CSS and JavaScript URL like
example.css?randomNo = Math.random()
Google Chrome has the Hard Reload as well as the Empty Cache and Hard Reload option. You can click and hold the reload button (in Inspect Mode) to select one.
I recently solved this using Python. Here is the code (it should be easy to adopt to other languages):
def import_tag(pattern, name, **kw):
if name[0] == "/":
name = name[1:]
# Additional HTML attributes
attrs = ' '.join(['%s="%s"' % item for item in kw.items()])
try:
# Get the files modification time
mtime = os.stat(os.path.join('/documentroot', name)).st_mtime
include = "%s?%d" % (name, mtime)
# This is the same as sprintf(pattern, attrs, include) in other
# languages
return pattern % (attrs, include)
except:
# In case of error return the include without the added query
# parameter.
return pattern % (attrs, name)
def script(name, **kw):
return import_tag('<script %s src="/%s"></script>', name, **kw)
def stylesheet(name, **kw):
return import_tag('<link rel="stylesheet" type="text/css" %s href="/%s">', name, **kw)
This code basically appends the files time-stamp as a query parameter to the URL. The call of the following function
script("/main.css")
will result in
<link rel="stylesheet" type="text/css" href="/main.css?1221842734">
The advantage of course is that you do never have to change your HTML content again, touching the CSS file will automatically trigger a cache invalidation. It works very well and the overhead is not noticeable.
You can force a "session-wide caching" if you add the session-id as a spurious parameter of the JavaScript/CSS file:
<link rel="stylesheet" src="myStyles.css?ABCDEF12345sessionID" />
<script language="javascript" src="myCode.js?ABCDEF12345sessionID"></script>
If you want a version-wide caching, you could add some code to print the file date or similar. If you're using Java you can use a custom-tag to generate the link in an elegant way.
<link rel="stylesheet" src="myStyles.css?20080922_1020" />
<script language="javascript" src="myCode.js?20080922_1120"></script>
For ASP.NET I propose the following solution with advanced options (debug/release mode, versions):
Include JavaScript or CSS files this way:
<script type="text/javascript" src="Scripts/exampleScript<%=Global.JsPostfix%>" />
<link rel="stylesheet" type="text/css" href="Css/exampleCss<%=Global.CssPostfix%>" />
Global.JsPostfix and Global.CssPostfix are calculated by the following way in Global.asax:
protected void Application_Start(object sender, EventArgs e)
{
...
string jsVersion = ConfigurationManager.AppSettings["JsVersion"];
bool updateEveryAppStart = Convert.ToBoolean(ConfigurationManager.AppSettings["UpdateJsEveryAppStart"]);
int buildNumber = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version.Revision;
JsPostfix = "";
#if !DEBUG
JsPostfix += ".min";
#endif
JsPostfix += ".js?" + jsVersion + "_" + buildNumber;
if (updateEveryAppStart)
{
Random rand = new Random();
JsPosfix += "_" + rand.Next();
}
...
}
If you're using Git and PHP, you can reload the script from the cache each time there is a change in the Git repository, using the following code:
exec('git rev-parse --verify HEAD 2> /dev/null', $gitLog);
echo ' <script src="/path/to/script.js"?v='.$gitLog[0].'></script>'.PHP_EOL;
Simply add this code where you want to do a hard reload (force the browser to reload cached CSS and JavaScript files):
$(window).load(function() {
location.reload(true);
});
Do this inside the .load, so it does not refresh like a loop.
For development: use a browser setting: for example, Chrome network tab has a disable cache option.
For production: append a unique query parameter to the request (for example, q?Date.now()) with a server-side rendering framework or pure JavaScript code.
// Pure JavaScript unique query parameter generation
//
//=== myfile.js
function hello() { console.log('hello') };
//=== end of file
<script type="text/javascript">
document.write('<script type="text/javascript" src="myfile.js?q=' + Date.now() + '">
// document.write is considered bad practice!
// We can't use hello() yet
</script>')
<script type="text/javascript">
hello();
</script>
For developers with this problem while developing and testing:
Remove caching briefly.
"keep caching consistent with the file" .. it's way too much hassle ..
Generally speaking, I don't mind loading more - even loading again files which did not change - on most projects - is practically irrelevant. While developing an application - we are mostly loading from disk, on localhost:port - so this increase in network traffic issue is not a deal breaking issue.
Most small projects are just playing around - they never end-up in production. So for them you don't need anything more...
As such if you use Chrome DevTools, you can follow this disable-caching approach like in the image below:
And if you have Firefox caching issues:
Do this only in development. You also need a mechanism to force reload for production, since your users will use old cache invalidated modules if you update your application frequently and you don't provide a dedicated cache synchronisation mechanism like the ones described in the answers above.
Yes, this information is already in previous answers, but I still needed to do a Google search to find it.
It seems all answers here suggest some sort of versioning in the naming scheme, which has its downsides.
Browsers should be well aware of what to cache and what not to cache by reading the web server's response, in particular the HTTP headers - for how long is this resource valid? Was this resource updated since I last retrieved it? etc.
If things are configured 'correctly', just updating the files of your application should (at some point) refresh the browser's caches. You can for example configure your web server to tell the browser to never cache files (which is a bad idea).
A more in-depth explanation of how that works is in How Web Caches Work.
Just use server-side code to add the date of the file... that way it will be cached and only reloaded when the file changes.
In ASP.NET:
<link rel="stylesheet" href="~/css/custom.css?d=#(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/css/custom.css")).ToString(),"[^0-9]", ""))" />
<script type="text/javascript" src="~/js/custom.js?d=#(System.Text.RegularExpressions.Regex.Replace(File.GetLastWriteTime(Server.MapPath("~/js/custom.js")).ToString(),"[^0-9]", ""))"></script>
This can be simplified to:
<script src="<%= Page.ResolveClientUrlUnique("~/js/custom.js") %>" type="text/javascript"></script>
By adding an extension method to your project to extend Page:
public static class Extension_Methods
{
public static string ResolveClientUrlUnique(this System.Web.UI.Page oPg, string sRelPath)
{
string sFilePath = oPg.Server.MapPath(sRelPath);
string sLastDate = System.IO.File.GetLastWriteTime(sFilePath).ToString();
string sDateHashed = System.Text.RegularExpressions.Regex.Replace(sLastDate, "[^0-9]", "");
return oPg.ResolveClientUrl(sRelPath) + "?d=" + sDateHashed;
}
}
You can use SRI to break the browser cache. You only have to update your index.html file with the new SRI hash every time. When the browser loads the HTML and finds out the SRI hash on the HTML page didn't match that of the cached version of the resource, it will reload your resource from your servers. It also comes with a good side effect of bypassing cross-origin read blocking.
<script src="https://jessietessie.github.io/google-translate-token-generator/google_translate_token_generator.js" integrity="sha384-muTMBCWlaLhgTXLmflAEQVaaGwxYe1DYIf2fGdRkaAQeb4Usma/kqRWFWErr2BSi" crossorigin="anonymous"></script>

How to build a less compilation chain (gulp -style) in Webpack v3?

For a new project I am bound to keep things webpack-only, and thus need to find a way to efficiently compile our stylesheets. Basically in a very gulh-ish way:
gather all less-files including glob-patterns like src/**/*.less (css order may be arbitrary)
also allow import of css files like, say ../node_modules/vendor/**/*.css or 3rdparty/master.less
(If I have to setup a bogus.js entry point for that, fine...)
And with all of that, a typical gulp workflow:
transpile less to css
merge (concat) less and css
have cssnano do its optimization job, with specific css nano options like e.g. orderedValues: false, normalizeWhitespace: true ...
write styles.css as final output
And of course:
have source-maps survive that chain for a styles.css.map
efficient watching and the usual lazy/incremental compilation (as gulp and webpack have it)
Something I do not need is css modules (css imported into node modules for 'scoped' use, coming out as hash-scoped selectors...)
How can a 'typical' less|css-processing toolchain be done in Webpack?
This SO question has my first attempt where I got stuck in config hell right in the middle after combining...
considerations so far (helpful or not)
I know, to webpack, any ressource including css or even font and images is a "module"... Rather than merging my css 'modules' with with actual js (only to later painstakingly separate them again later again), it might be wiser, to have an entry point cssstub.js in parallel – also known as multi-compiler mode.
But that's really, where my wisdom ends... doing a sequence of $things on a set of files in webpack seems really hard (unless it's a connected javascript module graph). I did find something on globbing, but that's not enough (merge css, cssnano,...) and mostly I simply can't glue the pieces together...
I have used gulp to build less and create corresponding maps like below:
First step compiles less and generated css in tmp folder
gulp.task('compile-less', function () {
gulp.src('./*.less') // path to your file
.pipe(less().on('error', function(err) {
console.log(err);
}))
.pipe(gulp.dest('./tmp/'));
});
Second step minifies generated css and create map files
gulp.task('build-css', ['clean'], function() {
return gulp.src('./tmp/**/*.css')
.pipe(sourcemaps.init())
.pipe(cachebust.resources())
.pipe(sourcemaps.write('./maps'))
.pipe(gulp.dest('./compiled/css'));
});
If you want you can add additional step to conact generated css.

grunt-wiredep - Want to get dependencies written into file

The common use of grunt-wiredep is to scan through your given HTML and inject the relevant dependencies into that HTML.
I'm looking to instead get the JS & CSS dependencies, in the order as determined by wiredep, concat them into a single JS and single CSS file and write those files.
I can see that wiredep itself is happy to return an object with an ordered list but the syntax for getting Grunt to write these into files is beyond me.
Does anyone know if this is possible and what the syntax would be? The first thing that all grunt-wiredep tasks start with is a source HTML file and that's not what I'm looking to do.
Any advice appreciated!
Thanks for your solution!
I've added some extra details, so it works out of the box:
//Put all bower files in one file
grunt.registerTask('bower-bundler', function() {
//Point to the file which source you need to bundle
var result = require('wiredep')({
src: ['index.html']
});
//Set grunt config for concat task based on result.js and add an output file
grunt.config.set('concat.withWiredepJS', {
src: [
result.js
],
dest: 'build/lib_min.js'
});
//Run the task right away
grunt.task.run('concat:withWiredepJS');
});
So the way I finally overcame this with a colleague is remarkably simple.
I set up a new Grunt task to get the object I needed from the node Wiredep process as here:
grunt.registerTask('bower-bundler', function () {
var result = require('wiredep')();
grunt.config.set('concat.wiredepCSS.src', result.css);
grunt.config.set('concat.wiredepJS.src', result.js);
});
The grunt.config.set() allows you to set a task's source outside of it's config block.

ServiceStack Bundler and sub-directory Less files

Until recentlly I was using the rather awkward dotless. I'm restricted to what I can use somewhat because I'm using VS2010, however I came across ServiceStack Bundler which seems to work great... apart from one thing.
My Less files are split using a directory structure - to simplify things, like this:
scaffolding/my-scaffolding.less
utilities/my-utilities.less
ui/my-ui.less
Each directories has many files, particularly with mixins etc.
In order to link them together, I've been using the #import function.
My main less file - main.less contains the following:
#import "utilities/all-utilities.less"
All utilities are listed here as it enables me to plug and play various file-sets. This code previously worked ok.
However I find ServiceStack won't pick up changes unless I reference all the less files individually and directly through the bundle file, which is a bit of a pain.
So, I can't use: main.less and import all sub files.
Instead, I have to use:
utilities/util1.less
utilities/util2.less
utilities/util3.less
and so on.
I'm using the ms build function to compile.
Any ideas?
/* UPDATE */
Tried the recommended answer below without success.
This is what I've tried so far:
Call a single less file that contains all #import declarations;
Does not trigger updates on compile.
Call all less files from bundle file and add #import statements to less files where necessary (note bundler won't compile without these);
Duplicates the #imported code as many times as the #import statement is used - even when (reference) directive is used, resulting in bloated/incorrect code.
You should be able to modify Bundler's bundler.js file to specify additional paths that less should search for when processing #import directives:
function compileLess(lessCss, lessPath, cb) {
var lessDir = path.dirname(lessPath),
fileName = path.basename(lessPath),
options = {
paths: ['.', lessDir], // Specify search paths for #import directives
filename: fileName
};
less.render(lessCss, options, function (err, css) {
if (err) throw err;
cb(css);
});
}
A mistake on my part, but one which wasn't easily spottable, so I'll post the reason for my problems so that others don't spend hours as I did chasing a solution to an unecessary problem.
I was using ServiceStack Bundler - I believe this issue would also have occured on on any solution using npm's less library.
My main issue was that none of my changes were triggered on compile. I use lots of #imports and numerous sub-directories for my less files so my first thoughts were the problem was due to subdirectories, and later, due to #import statements. However neither was correct.
I defined a bundle: main.css.bundle
Within the bundle I called my main less file that contained all the other #imported files: main.less
The issue was that less would normally reserve main.css, but the bundle also gives its output the same name based on the bundle name. So both were conflicting.
Change the bundle name or the main less file name and all should work.

Request multiple S3 files into one request

Is there a way to get multiple files from S3 (or any CDN) in one request?
For example, I have four files on S3:
example.com/cdn/one.js
example.com/cdn/two.js
example.com/cdn/three.js
example.com/cdn/four.js
I would like to be able to request any combination of them at a time. I currently have to include them separately:
<script src="example.com/cdn/one.js" />
<script src="example.com/cdn/two.js" />
But I would like to include them as one request:
example.com/cdn/code.js?one&two
I've considered combining the needed combinations into single files, but there will be way too many combinations for that to be realistic. I've also considered combining all of them into one file, but that would be ridiculously large.
First of all: Your question is more a JS thing than related to S3 / CDNs in general. And to answer your question: You can't "combine" them in one http request.
If you don't want to concatenate and minify them you should take a look at RequireJS, which could handle loading of your scripts – it's async and won't block the browser from rendering.
This is a really great article about async loading: css-tricks.com - Thinking Async which will give you a better insight.
EDIT after comment:
You can in fact use PHP to concatenate & minify your JS files on the fly, but this will put additional load on your server and you'll loose the benefits you get from a CDN … Another approach would be using a build system, which packs everything before it goes into production.
For further information on this topic take a look at the following links:
PHP5 - minify
PHP5 - Assetic
How do I concatenate JavaScript files into one file?
To do on the fly minifaction on your dev system (if it's a Mac) you may want to try CodeKit.
Here is one way you could do that (assuming you just use one&two&three and note file=one&file=two&file=3):
function getJs() {
var url = window.location.toString();
var query = url.split("?");
var params = query.split("&");
// iterate through array of params and write JS
for (i=0; i<params.length; i++) {
var name = params[i] + ".js";
document.write("<script defer language='javascript' type='text/javascript' src='" + name + "'><\/sc" + "ript>");
}
}
This should load after the page is loaded. Then in in your HTML perhaps. I haven't tested this but should be what you're looking for I reckon.

Resources