Extending the build script functionality

[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.

[paulirish]

how about data attributes?

<script data-build="libs.js" src="jquery.min.js">
<script data-build="libs.js" src="underscore.min.js">
<script data-build="libs.js" src="backbone.min.js">

<script data-build="app.js" src="plugins.js">
<script data-build="app.js" src="script.js">

I like it though. Very self describing. Would be nice to avoid an external YAML config file maybe potentially.

(at the same time i'm reading more about AMD modules and require.js and feeling sexy on those)

[necolas]

@mklabs has been playing around with these ideas here: https://github.com/mklabs/h5bp-build-script-tags/

[mklabs]

Some inputs:

Here is what using this kind of build script system would look like:

• using html comments: https://gist.github.com/1330325
• using data attributes: https://gist.github.com/1330332

In both cases, it feels really good using it. Changing the "bundles", their location, their content is a matter of tweaking the index.html files (possibly work on multiple html files).

Both approaches are valid, and both are very pleasant to work with.

[necolas]

Awesome. Some questions.

1. What is data-build-foobar="info" for? And is it meant to be included in the result?
2. How does the data-* approach know where to output the result?

[mklabs]

What is data-build-foobar="info" for? And is it meant to be included in the result?

data-buid-foobar is really here just for test purpose. I needed some values to work with in processors, and see how the $.data usage behaves. Indeed, any data-build* attribute should probably be cleaned out before replacing the original html markup.

How does the data-* approach know where to output the result?

Basically, the build script output stuff based on the current working directory. The current implementation does by outputting stuff in intermediate/ (because that's where the overall build script put stuff during the process). Then the value of data-build is used to:

1. Create the folder structure (if the value includes a deeply nested path)
2. Write the file content to the file system.

Note that this is close to the behavior of the html comments approach, where the last part of <!-- [[ build js lib/app.js]] --> is used in the same way.

[necolas]

Sorry, my fault, I meant how does it know where to insert the generated file in the HTML source.

[mklabs]

Well, this is slightly different for both approach:

• html comments: the markup is parsed to get each sections of html markup within <!-- [[ build ]] --> and <!-- endbuild --> marker. A processor result is used to replace the whole block, for each of them.
• data-attribute: The processors get the whole document to parse. It parses the dom tree to know each different bundles (that is data-build attribute on each link/scripts tags) that'll need to be dealt with.
  • For each of these, the processor tries to concat/rev files and generates the according file in the correct output location.
  • Finally, for each processed bundle, it removes any script/tags references and keep the very last one by changing the href or src attribute with the name of the bundle created.

[necolas]

Thanks :)

[addyosmani]

I liked the data-attribs approach to this personally :) @necolas are we waiting on more input/draft solutions from @mklabs to address the two proposals above before making a call a call on which to use?

[necolas]

Moved to h5bp/ant-build-script#4 and mklabs/node-build-script#1