Verify integrity of build artifacts for a yeoman angular project

npm install grunt-angular-verifybuild
2 downloads in the last week
17 downloads in the last month
<p>Verify integrity of build artifacts for a yeoman angular project</p>
<h2>Getting Started</h2>
<p>This plugin requires Grunt <code>~0.4.1</code></p>
<p>If you haven&#39;t used <a href="">Grunt</a> before, be sure to check out the <a href="">Getting Started</a> guide, as it explains how to create a <a href="">Gruntfile</a> as well as install and use Grunt plugins. Once you&#39;re familiar with that process, you may install this plugin with this command:</p>
<pre><code class="lang-shell">npm install grunt-angular-verifybuild --save-dev</code></pre>
<p>Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:</p>
<pre><code class="lang-js">grunt.loadNpmTasks(&#39;grunt-angular-verifybuild&#39;);</code></pre>
<h2>The &quot;verifybuild&quot; task</h2>
<p>The build process for angular+typescript (<a href=""></a>) based projects is
getting rather involved, partcularly because of the requirement to version all build artifacts other than
<code>index.html</code>. To make sure that the build process doesn&#39;t break down the line, we add a final verification stage
to the build process.</p>
<p>One can verify three things with the current implementation: existence of files, existence of revved versions
of certain files, and references from a file to a set of revved files. Verifying these conditions on certain
files will guarantee that the build ran successfully. An example of an unsuccessful build would be the partials
bundle, <code>templates.js</code>, containing the contents of <code>.html</code> partials <em>before</em> references to assets in them were updated
with their revved versions.</p>
<p>Probably obvious, but a representative set of files is enough, don&#39;t list all seven hundred of your asset files in the config.</p>
<p>In your project&#39;s Gruntfile, add a section named <code>verifybuild</code> to the data object passed into <code>grunt.initConfig()</code>.</p>
<pre><code class="lang-js">grunt.initConfig({
  verifybuild: {
    options: {
      exist: [
      revved: [
      revvedRefs: {
        &#39;index.html&#39;: [
        &#39;scripts/templates.js&#39;: [
        &#39;styles/styles.css&#39;: [
<p>Type: <code>String</code>
Default value: <code>grunt.config(&#39;yeoman&#39;).dist</code> || <code>&#39;&#39;</code></p>
<p>The directory that holds distribution artifacts.</p>
<p>Type: <code>Array of String</code>
Default value: <code>[&#39;index.html&#39;]</code></p>
<p>List of files whose existence is necessary for a successful build.</p>
<p>Type: <code>Array of String</code>
Default value: <code>[&#39;scripts/scripts.js&#39;, &#39;scripts/templates.js&#39;, &#39;styles/styles.css&#39;,]</code></p>
<p>List of files for which a revved version must be present. That is, in a successful build, if
<code>&#39;scripts/scripts.js&#39;</code> is listed in <code>options.revved</code>, something like <code>scripts/41a432de.scripts.js</code>
had better be present in the <code>dist</code> directory.</p>
<p>Type: <code>Map&lt;String, Array of String&gt;</code>
Default value: <code>{&#39;index.html&#39; : [&#39;scripts/scripts.js&#39;, &#39;scripts/templates.js&#39;, &#39;styles/styles.css&#39;,] }</code></p>
<p>For each key : refs, a possibly revved file key must contain at least one textual reference to the revved
names of each file in refs. So the text of <code>index.html</code> had better contain <code>0132abcd.scripts.js</code>,
<code>0132abcd.templates.js</code>, and <code>0132abcd.styles.css</code>. Yes, only the last part of the path is used in the matching.
This should be reasonably safe, because revved filenames have a content-based hash in the name, and are thus
fairly unique. If this proves to be a problem, we&#39;ll fix at that time.</p>
<p>I was going to write tests, but could not figure out how to test for grunt task failure, since it&#39;s the
failure of verification that&#39;s most interesting to test for. Will dig a bit more and come back to this later.</p>
<p>In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using <a href="">Grunt</a>.</p>
<h2>Release History</h2>
<p><em>(Nothing yet)</em></p>

npm loves you