Closed necolas closed 6 years ago
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
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:
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.