[thelist] Managing css, images, js versioning

[Bill Moseley]

On Tue, Dec 04, 2007 at 09:24:12PM -0700, Ken Snyder wrote:
> - Compile and minify js/css on demand.  On each page load, the server
> checks file version strings, timestamps or file md5's to see if that
> combination has ever been compiled into a file.

So the application source page might include:

    include_js( 'foo' );


Where load_js() might run out and find the current version needed, and
minify/compress if it doesn't already exist and finally output:


<script src="http://host.com/js/1223/foo.js" type="text/javascript"></script>

Where 1223 is the version?



> - Use apache rewrite to properly map versions to files.  Keep a config
> file or database with version numbers for each file.  In links, link
> to a filename with the version in it (e.g. myjavascript.1000.js).  Set
> up apache to map the file to the original name (e.g. myjavascript.js).
>  Clients are refreshed each time a version number is changed.  We
> actually did this with PHP on IIS even.

Yes, done that, too.  That's more for cache busting since it's always
pointing to the most recent version you have (i.e. you don't need
multiple versions of myjavascript.js at the same time).


In general, we are trying to reduce the number of separate css, js,
and images (sprites for images, minified, compressed and combined .js
and .css).  So, I'm less likely to use versions on files and instead
on entire directory trees:

    /
        js/
            123/  # version 123
                foo.js
                bar.js
            124/ # version 124 used by a newer application
                foo.js
                bar.js

        css/
            234/
                foo.css
            245/
                foo.css



> These ideas might not work well with js or css that include other
> files.  They would need to be served up by a dynamic language to
> update the filenames of included files.  Personally, I think that the
> developers should resolve dependencies server side and avoid js/css
> files that include other files.

But if under production:

    include_js( foo );

grabs a single minified file, then in development it's handy to have
foo.js include other js by inserting <script> elements rather than
having a it build on the fly every request -- mostly because the
developer sometimes might be serving the files directly w/o a server
that can build on the fly.


> You could also implement automation for updating of file/db configs
> using subversion hooks.
> 
> As far as shared files, we did a separate media repository.  With
> apps, you likely have one repository for each app.  If you share
> resources such as css, js, and images you may have success with one
> media repository with multiple branches.  That way, each branch of
> media can be merged or separated where needed.

The issue with shared files between different applications is that
it's very nice to have the item managed in one place (find out the
designer stole that icon and it needs to be replace then just change
it once and it's done for all sites.

On the other hand, if something gets changes globally it may have
unwanted side-effects on another site.  I see this happening with
javascript.  Imagine hosting YUI and the same YUI code is referenced
by a number of applications.  What if a new YUI version is released
that you need for a new feature in one application?  Then you have to
test all applications.

I think it some ways it's a safer approach to not share the files
across applications.

> Subversion really has the flexibility to complement your development
> process, so start by examining your development and deployment
> procedures.

Anything like hard links in svn?  Where you have a thin copy of a tree
of files and when they change on the original location they change in
the copy.  But if the copy is modified then it's a private and
different version.

-- 
Bill Moseley
moseley at hank.org