Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

basic working version of build script (ROUGH DRAFT) #25

wants to merge 1 commit into


None yet
4 participants

peterbe commented May 24, 2012

This is a rough draft to solve the problem with hosting tabzilla for optimal speed. Here's the bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=757559

  • The build script takes a copy of the css, img and js directories and puts them in a directory called build/latest/. Inside you'll find tabzilla.min.css and tabzilla.min.js.
  • It also copies the "latest/" directory and calls it by the latest git hash ID. e.g. build/versions/eab1444/
    I really wish tabzilla had a versioning scheme since that would be much more informative than a git hash. I.e. 1.2 > 1.1
  • You run it with make compile or just make which defaults to running verbose and with Google Closure compiler. You can alternatively just run python bin/build.py --uglifyjs yourself if you like.
  • You can also run make test which will serve up and open a test page referencing the minified versions.
  • uglifyjs is much faster than compiler.jar but produces a bigger output because it keeps the huge copyright comment.
  • The idea is that you set up a CDN or something with Cache-Control: max-age=3600 for the latest/ version and one with Cache-Control: max-age=315360000 for the versioned one.
  • MORE work is needed in tidying up the referencing of relative images. When minifying the tabzilla.css file we should re-write every local URI (e.g. /media/img/foo.png) to a relative one with and without a versioned filename (for the aggressive caching) (e.g. ../img/foo.eab1444.png). I wouldn't start using this build script and hosting it till this feature is cracked. However, it would for now just mean sub-optimal hosting of the images.

peterbe commented May 24, 2012

Opened up an issue to push on the versioning #26. Might be premature and is definitely not a blocker.


pmclanahan commented May 29, 2012

I was under the impression that the tabzilla resources were meant to be served from mozilla.org so that updates and changes could be immediately rolled out to everyone. Is that not the case?

peterbe commented May 29, 2012

@pmclanahan It's still the case. If you're working on www.mozilla-hacks.net you'll insert a <link> and <script> to //www.mozilla.org/tabzill/...


jlongster commented May 29, 2012

If a new site is built, are they supposed to get the URL with the hash somehow, instead of just linking to a generic mozilla.org/tabzilla.js ?

I like where this is going, thanks for the work on it! The closure compiler is good too, and we shouldn't need to recompile this often.

peterbe commented May 29, 2012

@jlongster they can choose. Same as you can do when you want to include the Google (CDN) hosted jquery. Either just reference the latest (minimal caching) or a specific version (optimal caching).

So you trade-off; speed versus convenience.
If you pick a specific version of tabzilla today you'll need to update your templates when a new version of tabzilla comes out but at least you get a very specific tabzilla which might be more predictable from a QA standpoint.

We have yet to figure out when and who will re-run the compilation. I'm guessing a webdev runs the build script but IT picks up the build and sticks it into whereever apache hosts it.

peterbe commented Jul 9, 2012

Any new thoughts on this?

I might just go ahead and finish the remaining features and land this.

peterbe commented Jul 27, 2012

PUT THIS ON HOLD. The thinking around how we can serve this stuff has changed quite a bit

The code needs to be refactored.


schalkneethling commented Jul 15, 2015

This repo changed a lot in the last day and I 'think' we will not require this anymore 😢 Thanks @peterbe but, I reckon we can/should close this one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment