A build script is necessary

[paulirish]

A build script is necessary

[paulirish]

http://github.com/Schepp/CSS-JS-Booster php
http://github.com/cjohansen/juicer/ ruby, no ie6-7 support.
http://github.com/mintdigital/asset_hat

[Garowetz]

How about SASS (http://sass-lang.com/) for css, since you're already using it.

Or maybe a post development compressor like the YUI Compressor (http://developer.yahoo.com/yui/compressor/). This will do both js and css

[paulirish]

on filename revving .. query params and caching; http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
http://wiki.squid-cache.org/ConfigExamples/DynamicContent

[vvo]

I can tell by experience that schepp cssjsbooster is the best option if dealing with dynamic scripts merge and minification.
It handles data uris, works with either closure compiler, yui compressor, jsmin.
Support filename reviving without query params.
It now has support for concurrency calls for generating cache. Easy integration either dedicated server or hosted sites.
Works only with php.

[Garowetz]

http://github.com/Schepp/CSS-JS-Booster

[roblarsen]

I'm partial to ant (or similar) for this task because it never needs a server or related infrastructure so it's more portable across projects. You can test with and deploy static files even. I've got a roughed out ant script that does the CSS/JS/file revving part. It should be pretty easy to add image optimization to it.

[Garowetz]

Does Ant need to be installed on most web hosts? Is there a stand alone binary/file that can travel with the boilerplate? Or is it generally already there on most good hosts?

[roblarsen]

An Ant based solution takes the power out of the host's hands and puts it in the hands of developers. Ant would need to be installed on any machine that was going to execute the build script. It's a Java app so that can be basically anything. The important part is the build script itself and that's a natural part of a project like this.

I don't think Ant is the only solution for this (it's basically an impossible problem to solve one-size-fits-all,) but it's definitely A solution. For a project with an inclusive scope like this there will likely need to be multiple options for these tasks,

I'll tweak this sample build script I put together a few months ago to work with this project. Hopefully that'll get the ball rolling on this issue.

[louisremi]

The first things we need are minifier APIs available over http. This would make it easier to create minification scripts in any language, without requiring the developers to install any library on their computer/shared host/server. We already have google Closure Compiler, we still miss CSS and HTML minification. What about starting an appEngine for that?

[unruthless]

Another PHP solution: http://code.google.com/p/minify/. Haven't used it, but have heard good things. Seems to be well-documented, too, and the mailing list is pretty active.

[louisremi]

What about adding and ... conditional comments for jQuery and profilers? This way, build scripts could automatically replace local jQuery by one minified and hosted on a CDN. and get rid of development scripts as well.

[Garowetz]

How about we define what we want in a build script, since this is a project of getting everything in one package

Must Haves

• Minify css and js
• Optimize Images
  • Yahoo Developer Network - Best Practices ...
  • Online web base tool Smush.It
• Pre Compress files - as suggested by Kroc Camen
• File name versioning (ie. style_v1.5.css)
• Build Once (either pre build or cache after first build)

Other Thoughts

• Able to work on as many hosts/dev comps as possible
• Use existing project(s) if possible
• Work with concepts like SASS

[louisremi]

I've got a fork of HTML-minifier with an option to switch from development to production mode: http://github.com/lrbabe/html-minifier/commit/1987ecd1cb6abecbf8202c6acb13ee690c4e8cef#L1R612

[roblarsen]

It's not the server side solution people want, but today I quickly put together and Ant build script that does the following:

creates a cleaned up "publish" directory (useful for a build kit, no extraneous files)
concats the project JS (my version moves jquery from the CDN to local source)
minifies it
revs the file name (min-001.js, etc.)
minifies the CSS
revs the file-name (min-001.css, etc.)
adjusts the source of index.html to point to the new files.

with Ant installed and on your path "ant build" in the project directory will make the above magic happen. I'm going to look into the image tasks next.

http://github.com/roblarsen/html5-boilerplate

[paulirish]

@rob, Totally kickass. This is really nice.

Ant looks like a good place to start this... it is kind of built for this exact thing and many folks already using Java for the yui compressor anyhow.

I think we could use more human-readable flags instead of @@SCRIPTS@@ and @@ENDSCRIPTS@@ but that can be adjusted.

Also obviously this will soon need to handle more than just index.html, we can iterate the html changes over a few files?

On image optimization, the Yahoo Perf link from above has the general techniques that Stoyan used on smush.it.. and then stoyans list of tools and google's page speed image optim deets

@Garowetz, definitely want these things done staticly at build time, instead of it happening on request. However I don't like static files that are pre-gzipped. Freaks me out.

@lrbabe, I'm all about html minification, though I only know of an ASP.NET html minifier and than kangax's.. Using a hosted minifier through an API is fine to me.. Can that work with Ant?
I like your prod/dev flag changes. I assume they're done in a way that means the production is commented out in dev and dev variant is in play?

(Somewhat tangential: found this ant script for identifying files based on filesize -- may be good for disabling gzip on files <1k in the future.

@ALL - thanks for your interest here. I think getting something here that could work for 80% of users will be absolutely HUGE. it's my favorite aspect of boilerplate.

[roblarsen]

@paul, yeah, the flags are definitely for the work-in-progress version. I'll swap for something more sensible now that that bit is working.

We definitely can do multiple HTML files as the replaceregexp task accepts a FileSet argument.

As for images, there's already an ant task for optipng http://github.com/znerd/optipng-ant-task, which gives me a decent place to start. I've looked through Stoyan's notes already, I'll take a look at Google's tonight. Hopefully it won't be too bad putting together the full sweep. Maybe I'll post to exceptional-performance to see if anyone there has done it.

[paulirish]

the task accepts a FileSet argument.

Hot.

Maybe I'll post to exceptional-performance to see if anyone there has done it.

Good call.

[Garowetz]

I like it ... I think I'll be learning ANT now!

[roblarsen]

Hey,

Update. I made the small changes to the index file to make the concat section a bit more friendly.

Also, I've been looking at the image optimization solution... it would be possible to hack something together using existing tools, but it wouldn't be an easy 80% solution. It'd be fine for project work, because you can just say "install X and make sure it's on your path." For this? Not a real solution. There's no equivalent to the YU Compressor jar that I can easily leverage for the task. Instead there are at least 3 or 4 tools, in different languages, that aren't going to be as portable in the way needed by a project like this.

I got crickets from exceptional-performance, as well.

I'll ask around to see if there's some way to smooth out the rough edges that lie outside my limited Ant experience. Maybe a web service? I know it's possible to post from Ant. I've just never done it.

What I'd really love to see is one, java-based tool we could compile and ship with the project.

I can also look at putting in some HTML minimization in. I might have more luck there.

[Garowetz]

Is there anyway would could implement the suggestion that Irbabe had above about production and not production. Might be useful for people moving from local to server.

Also do we think that a better more concise tag is better for identifying the script section. I like what was there before because it was smaller. You could still leave in the descriptive text letting users know what the section is for, but it would allow it to be smaller like we're trying to accomplish in the stripped version.

On the Image optimizing...

Could we include the binary's of some of the tools with the project? Would there be some way of distinguishing the operating system that the build script is on?

[roblarsen]

I can implement the production/non-production thing, at least as I understand the intent.

If you look at the output, the descriptive comments are actually completely stripped out by the build script, even without HTML minification. That said, I can make it read whatever folks want it to read. It's very flexible, as long as the first few characters are suitably unique. I'm happy to defer to Paul on the wording as the comments are in his editorial voice.

I can include some binaries and there might be some way to differentiate what OS is involved, but there are still way too many variable for me to feel like that's a solution that will scale to a bunch of different machines. I'll hit up some Ant geniuses to see if there's some technique I'm just ignorant to that'll solve this.

[Garowetz]

Yep I missed that those were stripped out!

[paulirish]

Thanks for the update Rob.

Is there anyway would could implement the suggestion that Irbabe had above about production and not production.

I really want to avoid all these flags over the markup that people need to understand in order to get their javascript served correctly. I think we can do this with the build process being a touch smarter.

Could we include the binary's of some of the tools with the project?

Yes i have no problems with that. I think a /build/ folder is in order and would do all this. I expect the build script to only be run on the webhost, so we're talking linux only. Running the build process locally is just ... bound for problems and so supporting win/mac for the build process just doesn't seem worthwhile to me. Any opposing views there?

These Ant intros are mostly for me, but for anyone else ... :
http://www.delicious.com/popular/ant
http://www.exubero.com/ant/antintro-s5.html
http://www.developer.com/java/j2me/article.php/989631/Building-with-Ant-Introduction.htm

[roblarsen]

if it's solely for linux, then I can more easily put something together.

Personally, I'd like to support win/mac local builds, (the above build should just work on any machine with Ant installed) but without some magic, I'm not sure that's going to be possible with the image optimization tasks included (at least in the short term.)

I'll take a look at a linux solution for the full build and then work in scaled down local targets (a "text" target or something that would just do the text optimizations.)

[paulirish]

I'd like to support win/mac local builds

That's probably the best move, yeah. .. What i'm trying to avoid is people who think all this is done locally somehow. I keep seeing stuff like "minimizing your javascript is good, but make sure to keep backups of your code." ugh.
And thus, I really think the build process should happen on a completely different machine so people aren't confusing the build process with what is (or, rather, should be) in source control.

I spotted http://trimage.org/ today which apparently has a commandline API and handles png/jpg. Might be a good project to leverage.

[roblarsen]

I was looking at it and, moving forward, there is actually a hook in ant to fork tasks based on the OS, so we can create a hodgepodge of binaries to take care of this task on multiple systems.

Looking at trimage now. Hopefully it'll shake out as it would be great to have one tool to do the compression taks on both pngs and jpgs.

[roblarsen]

trimage needs a gui, apparently.

Skipping that.

Checked in a version that runs optipng on /images/* It's SLOW. Definitely going to create a couple of target options- one for just text (which is fast and would likely need to happen more often just to test minification vs. breaking scripts) and then one for everything.

Gonna look at some jpeg stuff now. Once I get jpegs crunched, what's left for a serviceable version of this?

[roblarsen]

got distracted and enabled win (and mac? can't test- it should just work with optipng on the path) support for the optipng step. It's distributable, so I included the binary in the project. I'm going to find some time tonight/tomorrow to do the jpeg thing.

[roblarsen]

As long as libjpg (and jpegtran) are installed on your unix/linux/mac system, the PNG and JPG tasks are now working.

http://github.com/roblarsen/html5-boilerplate

I've got two basic targets "build" which does EVERYTHING (including images) and "text" which just works on the text components.

Take a look and let me know what you think. In addition to any feedback, I'll add some documentation to the build file so that people can tweak as needed.

[paulirish]

Oh this is good fun!
I've integrated your work into a branch (build) on my repo.

I moved build.xml and all of tools into a build/ folder, too.
In addition to that I made some more tweaks: http://github.com/paulirish/html5-boilerplate/compare/b7315160...c43f559

But in general I really like where this is going.

[roblarsen]

Stripping comments is a good start. HTML minification scares me a little bit, but dropping comments doesn't seem as much like a grenade with the pin pulled.

Let me know what else you might want to see it do.

[Garowetz]

This does look great ... few thoughts

• Readme file letting people know how to run the build script, and where to get ANT if they don't have it
• Some way of segmenting, so if they just want scripts and not image optimization they can get it. Good example of a file here: http://github.com/znerd/optipng-ant-task/blob/master/build.xml
• more comments in the build file to make it easier to see what's going on

(yes I know, I make suggestions when I could just commit it myself. I'm just so pressed for time right now, but I will get into it when I can)

[roblarsen]

The segmentation exists already, although it could be improved. For example, right now, you can run "ant scripts" and it will copy the files over, concatenate them, rename them, minify them and change the source reference without running any of the other targets. I really just need to look at the dependencies to make sure each valuable target works as expected by itself.

A readme would be great and some more documentation in the build file would definitely be good.

[paulirish]

I added some crude ability to switch to the minified jquery, if you're currently using the unminified..
http://github.com/paulirish/html5-boilerplate/commits/build
And also a feature in the minification where <!--! comments --> are retained, but the rest are dumped.

We can also look at
http://code.google.com/p/htmlcompressor/
which kangax calls the best option at the moment. I'm just not sure how we can use his js-based one feasibly. Sad.

Rob, you can pull in from my build branch if you wanna tweak any more or whatever.

I guess the thing that is most pressing is the need to apply this to a set of .html files. I kinda did that down in the htmlmin section but that direction doesnt look very DRY. I also think about when people add a few jQuery plugins (or whatever 3rd party scripts) that require extra CSS..
How we fold in the new js and css files into the concat/min process here. Ideas?

[Garowetz]

What do you mean by "js-based"?

This htmlcompressor looks like it'll do everything we want. And even suggests ANT as an option. It includes YUI too! Still doesn't do the image optimizations but we've got that. I like it.

I take it we're not going to be able to dictate how users should include their js and css files are we.

[roblarsen]

Anywhere we need to do multiple file replace, the pattern looks like this:

<replace dir="${src}" value="wombat">

<include name="*/.html"/>

<replacetoken><![CDATA[multi line

token]]></replacetoken>

</replace>

exclude works there as well, so it's pretty straightforward.

@paul If I have time before the weekend (I'm out of town Friday/Saturday) I'll look at your branch and try to add some documentation, check out htmlcompressor, etc. If not, I can tackle whatever's left when I get back.

[paulirish]

What do you mean by "js-based"?

I meant kangax's html minifier. http://kangax.github.com/html-minifier/

Also yeah it looks like the htmlcompressor can run YUI on inline script/style which may be all we want it for.. I'm still a little wary about full whitespace removal. :)

I take it we're not going to be able to dictate how users should include their js and css files are we.

Not exactly, but if they would like to have 8 js files included and have the build process smush em all together, they have to follow a few guidelines.

[paulirish]

Just spotted this.. a rake port of the build script:
http://github.com/avdgaag/html5-boilerplate/commits/rake

Very nice. Will be great to have this as an option for all the rubyists.

[roblarsen]

Very cool.

[mikkotikkanen]

Coolness.

What I would like to see is configurable ant script, in order to have it compatible with different types of file/folder structures and/or names. Which is bound to happen. Luckily this is easily done by using hefty set of properties.

The reason for this is that people will have, and will want to have, different configurations with their systems because of different requirements. For example, having single or even two script files, or even in one single folder, is just not feasible for larger projects, thus one should be able to easy to configure.

For example, I am using automated js-test-driver unittesting and scripts folder having java-like folder (/packet) structure, in order to handle all the files for our framework. This framework is then concatenated and minified upon publish.

Also, the order the files are concatenated together should be taken into account. Many JS frameworks offer possibilities to build your own framework libraries (for smaller filesizes), thus library files should be before the user written files in the final concatenated file.

Personally, I do this in the way that you define the library fileset (usually just scripts/libs//__) separately from scripts fileset (usually scripts/libs//**, excluding scripts/libs). These two are first concatenated together as two files, which are then concatenated together, with libs-concat being first.

When these would be defined in the "head" of the build script, the configuration and customization for each need would be a breeze.

[mikkotikkanen]

Oh, would like to see the compressor to also be able to handle php files.

[paulirish]

mikko. thanks a bunch for your interest.
would you be interested in forking and adding in support for this sort of configuration?

The most up to date build stuff is at
http://github.com/paulirish/html5-boilerplate/commits/build

I agree with you on the flexibility, for sure.

[mikkotikkanen]

I will check it out if I could incorporate parts from our build script.

Oh, and also, it needs to ignore .svn folders.

[paulirish]

mikko,
this commit from garowetz probably makes sense to integrate while you're pumping up the build.properties changes:
http://github.com/Garowetz/html5-boilerplate/commit/ff3d10eaff956

[paulirish]

I've integrated garowetz's best practices commit (a bit sloppily, sorry!)
and added a few build options based on your intended output..

Also updated htmlcompressor which has a bugfix coming directly from a boilerplate user! http://code.google.com/p/htmlcompressor/issues/detail?id=16

newest is on build branch
http://github.com/paulirish/html5-boilerplate/commits/build

mikko, can you build out your configuration work from here?

[paulirish]

I've also added a rough wiki page for documentation that we can build out: http://github.com/paulirish/html5-boilerplate/wiki/Build-script

[mikkotikkanen]

Paul, I'll check it out when I get a bit time for it. :)

Quite swamped at the moment (it's 23:50 in here and I'm still working, started 9:00 at the morning) with some architecture changes to our framework and development processes. Need to get this stuff done before it is needed in development.

[mikkotikkanen]

Can we reserve the publish/build etc. directories to ourselves or should we think of different folder structure? People might want to have build/publish etc. directories on their site- Either group all boilerplate folders under one folder (/boilerplate) or have the actual site living in "application/" folder, this way we could have "build/", "publish/" and even "demo/" sitting right next to it, without breaking anything.

[roblarsen]

I think there's a danger of overthinking the way this might be used.

I mean, I've already used boilerplate on a project and the first thing I did when I exported was change the folder structure for static assets to match the way I prefer it (js, images and css as a subfolder of a new folder called _assets.) I don't need Paul's master to change to suit the way I'm going to use it.

Especially since I'm using it to just create a transitory set of templates that will be passed off to some back-end guys to get wrapped into an application. All of the directories outside those referenced in the HTML could have gibberish names in my case since, at some point soon, my boiler plate directory will be left behind.

I think we should just provide a smart, common sense default and then document the hell out of the ways to customize it (a task I'm hoping to work on this weekend.)

[mikkotikkanen]

Well, the thing is, now that it has the js, css, html and image optimizations, it probably will be used as a base for web-pages: Person X would take the boilerplate and build their site off from that, so that the whole site can utilize the optimizations scripts.

[roblarsen]

To me, the optimization steps are, by nature, final so they're going to be used in a lot of different ways. I just don't think we can predict the way in which this is going to be used so optimizing the process against any one use case just makes it more awkward for some other use case. I can guarantee you I will NOT be carrying the actual boilerplate directory over to projects at work. I will be packaging up files in the publish directory and passing them along to back-end developers for integration in a CMS or application. This will happen almost every time I use the project. We'll leverage the ant tasks for the project builds (when we're using Ant, of course,) but the actual export of boiler plate will be long gone.

I'm fine with doing whatever people think makes sense, as I said, I'm going to customize this every time I use it anyway, so the folder structure doesn't matter. I just think sticking to easy-to-grok folder structure makes sense. By name, /build indicates "oh, this is where the build files live" without having to resort to reading documentation. Of course, moving the build.xml up a directory to the project root would make it more standard, but /build is pretty straightforward.

[mikkotikkanen]

The projects I'm working on, won't be using the build script either, as there is already one that is doing stuff and running on CI. To projects like this, the structure won't really matter as, just like you said, it's exported once and that's it.

However, I'm just trying to think this also from the point of view of lone developer, who want's to build his site off from boilerplate. A) they most likely would want to leverage the build scripts, instead of say, using optimization services and B) to web-developers, who haven't been doing application development with compiled languages, the conventions of build/ etc. folders aren't that clear, since there is no build/publish process in traditional web-development. Thus, it would probably make most sense to them, if the whole boilerplate would just live at it's own folder as a whole. The problem with this approach however is, where do you put the publish/ folder?

The folder names themselves will be configurable, so the issue could be remedied by the user themselves. However, I'm trying to think of an case which would require the least of configuration by the user, making the boilerplate true bolt-in enhancement.

[roblarsen]

There's just no way to make this work, without customization, for everyone. For the lone developer? Hopefully the documentation will be clear enough that they're be able to figure it out without too much trouble. You STILL need to go through the build step and that can only happen on a copy of the site files, so they're going to have to work in the idea of a separate directory for their files.

I'm just wary of overcomplicating it in order to have it be all things to all people right out of the box. People are going to have to customize this. All we can hope to do is make that customization as easy and as clear as possible.

[mikkotikkanen]

Not really seeing your point of having two separate directories.

Here's what I've been thinking for the Javascript build

Scripts folder (js/) would then have structure like this:
js/libs (Contains all library files)
js/helpers (Contains libraries for specific cases, like IE png fix)
js/scripts (User written scripts)

The script would concat libs as one file, scripts as one file and then, if set, would concat these two together, so that the file containing the libraries would always be on top. Then the resulting file would be minified. Files in helpers/ folder would never be concated together, or to the main scripts, as these are meant for specific cases only. Wouldn't make to include these to main scripts. Then the js folder would be cleaned.

The reason there is /scripts subfolder inside the js/ folder is that this structure allows people to add other libraries, profiling tools etc. to js/ folder, while still having the ability to have any sort of structure (of subfolders) inside the js/scripts folder.

Now we would just need some regexp wizardy to replace all "/js/scripts/subfolder" etc. calls with "/js/scripts-008-min.js". Same with libraries.

[roblarsen]

I'm confused, are you suggesting we work directly on source files/directories and not have a separate ./publish directory? Working with a separate directory makes builds safe and cheap. Something went wrong? Fix your script and run it again. Since it cleans the directory you can make disasters go away with one line.

[mikkotikkanen]

Of course not. But can't really see why the user would be forced to work with two separate directories.

[paulirish]

"two separate directories" I guess you're talking about build and publish?

Ah I think you may be proposing ./build/publish as the destination for all files?
That's not bad. I don't see too much wrong with that structure, assuming it is documented. :)

btw guys I'll be in here for a while today: http://www.chatterous.com/html5boilerplate/

[mikkotikkanen]

I was actually commenting on Rob's post :) ("You STILL need to go through the build step and that can only happen on a copy of the site files, so they're going to have to work in the idea of a separate directory for their files.") Not sure what he meant by that. I guess it's a common symptom today. :P

[roblarsen]

Ah, I see. I was only ever referring to the ./publish directory. Not that the developer would somehow need to keep two sets of source files.

[roblarsen]

hey, back from a free-time coding blackout. Any interest in adding this task in?

http://htmlcssjavascript.com/javascript/an-ant-task-to-comment-out-console-log-calls-from-javascript-files/

[mikkotikkanen]

Hey. That actually is already implemented in the current version of the build.xml. ;) Now that I finally finished things to do today, I could see if I can manage to commit (never worked with git or github before :/) the changes I did to github.

[roblarsen]

hah, shows you how much I've been paying attention. I was reminded of the task today because of this discussion making the rounds (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694) and then thought about boiler plate and how I've been out of the loop for a little bit (damn work-work getting in the way.)

[mikkotikkanen]

Hehe. You're still in the loop since the build file has been sitting on my computer for ages, it's not on the internets yet. :/ Same here with work-work (building two businesses at the same time can be exhaustive, I've learned), been pretty much swamped with that stuff (12-16 hours per day) +had to finish a project ASAP (developers4cause.com) thus haven't had any extra energy to think about boilerplate. :(

But now, first something to eat and then I'll try to push some stuff to the general direction of the github. :)

[mikkotikkanen]

I'ts utterly infuriating how the good idea behind git has been completely destroyed by the useless complexity of the whole process. After an hour of screen after screen of completely unintuitive interfaces and random error messages ("rejected".. aight), finally got something pushed to my fork: the build.xml. However, no matter what I do, the new structure of js/ folder wont go anywhere. Nor can I get it rolled back to the form it is in github. Splendid. Makes me feel like smashing things into things.

So, the structure inside the js folder should be as follows:
js/main - Should contain script.js and plugins.js
js/helpers - Should contain the dd_belatedpng.js
js/libs - Should contain the jQuery

Files inside main and libs will bet concatenated together, minified and moved to js/ folder
If set, libs and main will be concatenated together as one file
Helpers will only be minified, and kept in the helpers folder

[mikkotikkanen]

Oh. And forgot the the default.properties. Can't seem to be able to push that neither but made the commit by hand to my fork.

http://github.com/mikkotikkanen/html5-boilerplate/blob/build/build/default.properties

[paulirish]

mikko, i'm digging into your changes now and hope to land them in my build branch

[paulirish]

Okay cool. I made the new folders.. and tweaked a few bugs in the process.
http://github.com/paulirish/html5-boilerplate/commits/build

A few questions for Mikko:

<replaceregexp match="(console.log\(.*\))" replace="/\*\1\*/"

Should this console log regex be ungreedy? I think code like: console.log('omgomg'); actualThings(); console.log('sldfj'); will break it.

Right now the default build will remove the unminified (but concatenated) scripts by default. Earlier we had it so they were still available (someone can remove the .min from the filename and see the thing). I'd like to have it like that by default. Does that mean js.delete shouldn't be run by default?

Also..
jQuery is included in scripts.min but we're also requesting it from the CDN. Probably better to keep it out of the minified scripts-xxxx.min.js. yah?

[paulirish]

Also this is super cool. :) I like the flexibility of the default props.

Still have some questions about how people add new CSS and HTML files and such.. Not really sure how we include them into this setup.

[mikkotikkanen]

Yeah, it probably should be. That was just the way I got it working, and since I'm not a regexp lover, I left it at that so that someone who is actually adept with that stuff can change it to something better. :)

That is basically the way our project does things (or used to do, currently doing a rewrite) so that's why it acts the way it acts. So it's not something that should be necessarily taken as is, but set to the way you want it to work. So yeah, if you want to, the script can still hold on to non-minified files. The reason I use it that way is that the stuff in publish folder is considered "final" and ready for deployment, thus there really shouldn't be any unnecessary files there, as the development itself happens in the main folder.

What do you want to do with HTML and CSS?

[maniqui]

Regarding the filename revving, what do you think about implementing this trick?
http://www.askapache.com/htaccess/mod_rewrite-fix-for-caching-updated-files.html

It makes deployment easier, as files doesn't have to be renamed. Only the references on the HTML.
Apache takes care of the rest.

[roblarsen]

That's very cool. I'm not sure it's that much of a saver here as we still need to minify and rename the files to indicate min.status. Still, a nice option to have and it would be seamless (at least for people using Apache- IIS, Nginx, lighttpd, etc. users would still be better served by the build process as it stands. )

So, yeah, what is the goal with the HTML and CSS? We can just sweep the directory for both (unless there's a desire/need to concatenate CSS as well, in which case we need to be a bit more discerning and do a bit more work) and process accordingly.

[paulirish]

CSS

we can only concatenate css if the media type is the same. (can't smush print styles along with screen/all styles). I think this means we gotta parse the markup? :/
is there a way we can avoid that? just have more configuration?

here are three recent sites done with BP to get a feel for how this'll pan out.
http://www.waiterontheway.biz/ http://lostworldsfairs.com/ http://coleman.depaul.edu/

HTML

Doesn't seem as bad. We now have a config where a user can specify which files should be affected. (Though could someone help me with what that would look like?)
http://github.com/paulirish/html5-boilerplate/blob/build/build/default.properties#L35-38

I imagine the two primary use cases here are people running the build tool on a bunch of HTML files that share the same header/footer/blah.. and then people who have a structured template setup. The build script should handle both those well.

[paulirish]

YEEEEE HAW!!!

I just merged build into master. All our build work will be in the upcoming release of HTML5 Boilerplate with a Beta sign on it. :)

I changed around some of mikko's work where the javascript got split into four different folders. (I moved script.js and plugins.js back in to just /js/) But this made some good headaches for me.. I'm still working on them now.. if anyone wants to help me take a look, that'd be great. I'll be in http://www.chatterous.com/html5boilerplate/

The remaining issue we had from before regarding making the buildscript flexible with additional html/css files has been broken into issue #143.

I'm closing this ticket now. :)

Thanks everyone for your help thus far on probably the coolest part of html5 boilerplate!

[paulirish]

If anyone didn't see.. we released v0.9.5 with the build script..
Now to get some feedback on it.. make it more stable.. and maybe some new features..

speaking of features:
http://github.com/paulirish/html5-boilerplate/issues/issue/165

i've roughed out some ideas there. please feel free to add your own.
and also give the build script a whirl!