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

Extending the build script functionality #4

Closed
necolas opened this Issue Feb 3, 2012 · 3 comments

Comments

Projects
None yet
3 participants
Owner

necolas commented Feb 3, 2012

Ported from h5bp/html5-boilerplate#831
Originally opened by @necolas

Just sharing an idea about how the build script might be adapted to move some of the configuration into the HTML, and maybe make it more flexible and accessible to front-enders at the same time. It might be a bit ridiculous but here goes...

Pretty much every build script I've had to work with involved listing the files to be minified/concatenated in groups in a configuration file, sometimes that name and location of the output file was included there too. Then a line of server-side code is placed in the template to mark where the generated file should be output in the HTML source in the production environment.

The JS concatenation stuff is sort of like that but hard-coded and limited. Maybe we could expand upon it and make the comments more obviously related to the build script and exist in discrete blocks. An idea I discussed with @mklabs was to have some sort of "build script tag" in the HTML comment. For example:

<!-- [[ build css site.css ]] -->
    ...stylesheets...
<!-- [[ endbuild ]] -->

<!-- [[ build js head-scripts.js ]] -->
    ...scripts that need to be in the head...
<!-- [[ endbuild ]] -->



<!-- [[ build js libs.js ]] -->
    ...libraries...
<!-- [[ endbuild ]] -->

<!-- [[ build js site.js ]] -->
    ...all your jquery plugins...
    ...developer authored scripts...
<!-- [[ endbuild ]] -->

Everything inside a "build block" would be minified, concatenated, and revved into the '[md5].site.css' filename based on the one that is specified in the comment. You could use whatever name you want. And anything @import-ed inside those stylesheets would be included too.

The 'css' part would be a label to attach specific customisations made from within the config file like the compression library used and the output directory. So 'css' might specify to use YUI's compressor and output to /publish/css/site.css. You might just have 1 for CSS and 1 for JS, or maintain several different patterns.

Not sure how things would be handled if your moved the files around relative to each other (e.g. the image paths in the CSS), or how the check would work to make sure you weren't rebuilding unchanged files.

Anyway, that's it.

Owner

roblarsen commented Feb 10, 2012

I'd never even looked at this issue originally. 3 months ago. I was jammed then, so that makes sense. I really like this.

Contributor

alvincrespo commented Feb 10, 2012

@necolas That exactly the way some of my previous projects handled their own build scripts. It would be great to have this implementation to detect these comments, and if they exists to do what you mentioned above. My only question is how we would go about concatenating the scripts - meaning, would they be in their own configuration file (xml/json) or would we use regex to do the detection and get the files?

I prefere a configuration file, but the downside is that you would need to change the location in your html and your config file if anything is moved around.

Owner

roblarsen commented Jan 17, 2013

This is actually in place now with the new https://github.com/h5bp/ant-build-script/blob/1.0/tools/FindAttribute.java which can open any tag, inside any set of formatted comments and grab any attribute. This will get extended around in a few places

@roblarsen roblarsen closed this Jan 17, 2013

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