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 #1

necolas opened this Issue Feb 3, 2012 · 1 comment


None yet
2 participants

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 ]] -->
<!-- [[ endbuild ]] -->

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

<!-- [[ build js libs.js ]] -->
<!-- [[ 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.


mklabs commented Mar 9, 2012

I've been thinking a lot lately of what the overall api could look like. I've quickly setup rough ideas related to this in a wiki page: https://github.com/h5bp/node-build-script/wiki/jsdom-implementation

Next step is to actually do something useful with that :p

@mklabs mklabs added a commit that referenced this issue Mar 14, 2012

@mklabs mklabs dom - a start on dom-based build using jsdom
seems like a good starting point, doing most of the stuff outlined in

the only plugin (partially) implemented is link for now.

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