Rerigging Support

[DamonOehlman]

Had a thought last night about implementing reinclude support. Basically, thinking about something like:

//= github://buildjs/shims/string/trim.js
console.log('test '.trim());

currently is converted into the following:

// https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/Trim
if(!String.prototype.trim) {  
  String.prototype.trim = function () {  
    return this.replace(/^\s+|\s+$/g,'');  
  };  
}
console.log('test '.trim());

But, I think the following would be more useful:

//++ github://buildjs/shims/string/trim.js
// { "etag": "c2edca3e5a8d676bc7ad7941260b544b" }
// https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/Trim
if(!String.prototype.trim) {  
  String.prototype.trim = function () {  
    return this.replace(/^\s+|\s+$/g,'');  
  };  
}
//-- github://buildjs/shims/string/trim.js
console.log('test '.trim()); 

While the extra comments do add a little extra noise to the resulting output, they do provide a mechanism that would allow rerigging the file.

Primarily, my reasons for considering this is that using Chocolat's node integration I could enable people to rig inline while editing their code to bring in useful snippets rather than copying and pasting code. To ensure these snippets were up-to-date you would simply have to rerig the file.

Thoughts?

[DamonOehlman]

Oh, and the comment line after the //++ comment is just a sample that demonstrates the ability to associate some additional information with the include. Storing e-tags could be a useful way to avoid rerigging when the code is already at the latest version.