Skip to content
This repository
Browse code

Convert docs to use fenced code blocks again

  • Loading branch information...
commit 32b634057f7250a6cd0c55986b72f59146b202ba 1 parent f5fd21b
Sindre Sorhus authored
35  docs/cli/commands/build.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#build" name="build">build</a>
4 2
 
5 3
 Usage: `yeoman build`, `yeoman build:<target>`
@@ -63,24 +61,21 @@ setup each time.
63 61
 
64 62
 The following is the relevant block to edit within your Gruntfile:
65 63
 
66  
-{% highlight javascript %}
67  
-    // rjs configuration. You don't necessarily need to specify the typical
68  
-    // `path` configuration, the rjs task will parse these values from your
69  
-    // main module, using http://requirejs.org/docs/optimization.html#mainConfigFile
70  
-    //
71  
-    // name / out / mainConfig file should be used. You can let it blank if
72  
-    // you're using usemin-handler to parse rjs config from markup (default
73  
-    // setup)
74  
-    rjs: {
75  
-      // no minification, is done by the min task
76  
-      optimize: 'none',
77  
-      baseUrl: './scripts',
78  
-      wrap: true
79  
-   }
80  
-{% endhighlight %}
  64
+```js
  65
+// rjs configuration. You don't necessarily need to specify the typical
  66
+// `path` configuration, the rjs task will parse these values from your
  67
+// main module, using http://requirejs.org/docs/optimization.html#mainConfigFile
  68
+//
  69
+// name / out / mainConfig file should be used. You can let it blank if
  70
+// you're using usemin-handler to parse rjs config from markup (default
  71
+// setup)
  72
+rjs: {
  73
+  // no minification, is done by the min task
  74
+  optimize: 'none',
  75
+  baseUrl: './scripts',
  76
+  wrap: true
  77
+}
  78
+```
81 79
 
82 80
 See the official project [repo](https://github.com/jrburke/r.js) for more information on the
83 81
 options supported by r.js.
84  
-
85  
-
86  
-
5  docs/cli/commands/help.md
Source Rendered
... ...
@@ -1,11 +1,10 @@
1  
-
2 1
 ## <a href="#help" name="help">help</a>
3 2
 
4 3
 * `yeoman --help` or `yeoman help`
5 4
 
6 5
 Lists out the commands and tasks supported by yeoman and should print out the following to the console:
7 6
 
8  
-{% highlight sh %}
  7
+```sh
9 8
 yeoman init      # Initialize and scaffold a new project using generator templates
10 9
 yeoman build     # Build an optimized version of your app, ready to deploy
11 10
 yeoman server    # Launch a preview server which will begin watching for changes
@@ -17,6 +16,6 @@ yeoman update    # Update a package to the latest version
17 16
 yeoman list      # List the packages currently installed
18 17
 yeoman search    # Query the registry for matching package names
19 18
 yeoman lookup    # Look up info on a particular package
20  
-{% endhighlight %}
  19
+```
21 20
 
22 21
 Note that commands may also support additional flags and so we recommend consulting the documentation for specific commands for the complete details.
56  docs/cli/commands/init.md
Source Rendered
@@ -16,8 +16,7 @@ By default we support Compass and CoffeeScript, so if your project includes any
16 16
 
17 17
 If everything has been installed successfully, running `yeoman init` will present you with a welcome screen to kick off your project that looks a little like this:
18 18
 
19  
-{% highlight sh %}
20  
-
  19
+```sh
21 20
         _   .--------------------------.
22 21
       _|o|_ |    Welcome to Yeoman,    |
23 22
        |_|  |   ladies and gentlemen!  |
@@ -32,71 +31,60 @@ Out of the box I include HTML5 Boilerplate, jQuery and Modernizr.
32 31
 
33 32
 Please answer the following:
34 33
 [?] Would you like to include Twitter Bootstrap for Compass? (Y/n)
35  
-{% endhighlight %}
  34
+```
36 35
 
37 36
 ### custom generators
38 37
 
39 38
 Some of our supported custom generators include:
40 39
 
41  
-{% highlight sh %}
42  
-yeoman init bbb      #backbone boilerplate
43  
-yeoman init angular  #angularjs seed
44  
-yeoman init ember    #ember app based on ember-rails
45  
-{% endhighlight %}
  40
+```sh
  41
+yeoman init bbb      # backbone boilerplate
  42
+yeoman init angular  # angularjs seed
  43
+yeoman init ember    # ember app based on ember-rails
  44
+```
46 45
 
47 46
 Yeoman comes with a powerful system of Generators for scaffolding out applications using any number of boilerplates, frameworks and dependencies. Generators can be called in a project which has already been initialized with a basic Yeoman application structure OR may contain all of the files needed for the application structure themselves. By default, one can call a generator as follows:
48 47
 
49  
-{% highlight sh %}
50  
-yeoman init generatorName #e.g yeoman init angular
51  
-{% endhighlight %}
  48
+```sh
  49
+yeoman init generatorName # e.g yeoman init angular
  50
+```
52 51
 
53 52
 In the case of a Generator named "angular", a grouping sub-generator called `all` may exist for scaffolding out all of the files needed for a new AngularJS application. One would use this as follows:
54 53
 
55  
-{% highlight sh %}
56  
-yeoman init angular:all
57  
-{% endhighlight %}
  54
+    yeoman init angular:all
58 55
 
59 56
 The idea here is that the Generator would pull in AngularJS, its common dependencies and write out the boilerplate needed for a basic Controller and any other components the framework may require.
60 57
 
61 58
 As we understand that it's unlikely a user will wish to manually type out the ":all" part of each generator, we support a catch-"all". If a generator has a sub-generator (grouper) called "all" we will attempt to call "all" when you try running the top-level generator. This allows a user to simply call:
62 59
 
63  
-{% highlight sh %}
64  
-yeoman init angular
65  
-{% endhighlight %}
  60
+    yeoman init angular
  61
+
66 62
 and has it defer to `angular:all` automatically.
67 63
 
68 64
 If one then wishes to create further AngularJS controllers, one can simply call the 'controller' sub-generator as follows:
69 65
 
70  
-{% highlight sh %}
71  
-yeoman init angular:controller controllerName
72  
-{% endhighlight %}
  66
+    yeoman init angular:controller controllerName
73 67
 
74 68
 where `controllerName` is the name of the Controller you wish to create.
75 69
 
76 70
 Similarly, a Backbone.js Generator may be used as follows:
77 71
 
78  
-{% highlight sh %}
79  
-yeoman init backbone
80  
-{% endhighlight %}
  72
+    yeoman init backbone
81 73
 
82 74
 where the above would result in boilerplate for models, views, collections and a router being written to the current application directory, as well as Backbone.js and its dependencies being pulled in. One could then call the different sub-generators for the Generator as follows:
83 75
 
84  
-{% highlight sh %}
85  
-yeoman init backbone:model modelName
86  
-yeoman init backbone:collection collectionName
87  
-yeoman init backbone:view viewName
88  
-yeoman init backbone:router routerName
89  
-{% endhighlight %}
  76
+    yeoman init backbone:model modelName
  77
+    yeoman init backbone:collection collectionName
  78
+    yeoman init backbone:view viewName
  79
+    yeoman init backbone:router routerName
90 80
 
91 81
 To list out all of the generators currently available locally, you can use the `--help` flag as follows:
92 82
 
93  
-{% highlight sh %}
94  
-yeoman init --help
95  
-{% endhighlight %}
  83
+    yeoman init --help
96 84
 
97 85
 This will print out a list of existing generators, including some of the below:
98 86
 
99  
-{% highlight sh %}
  87
+```sh
100 88
 Please choose a generator below.
101 89
 
102 90
 Yeoman:
@@ -115,4 +103,4 @@ Backbone:
115 103
   backbone:router
116 104
   backbone:view
117 105
   backbone:collection
118  
-{% endhighlight %}
  106
+```
32  docs/cli/commands/install.md
Source Rendered
@@ -8,47 +8,41 @@ By default, running `yeoman install packageName` will install the dependency in
8 8
 
9 9
 Example:
10 10
 
11  
-{% highlight sh %}
  11
+```sh
12 12
 yeoman install backbone
13 13
 
14 14
 # or if you wish to install multiple packages at once..
15 15
 yeoman install jquery spine
16  
-{% endhighlight %}
  16
+```
17 17
 
18 18
 As mentioned, the files for these dependencies will be added to `app/components`. If you wish to use any of them you will need to manually include a script/file reference to the relevant source files.
19 19
 
20 20
 Example:
21 21
 
22  
-{% highlight html %}
  22
+```html
23 23
 <script src="components/spine/lib/spine.js"></script>
24  
-{% endhighlight %}
  24
+```
25 25
 
26 26
 If installing a dependency which has its own dependencies described, these dependencies will also be pulled in.
27 27
 
28 28
 Example:
29 29
 
30  
-{% highlight sh %}
31  
-yeoman install backbone
32  
-{% endhighlight %}
  30
+    yeoman install backbone
33 31
 
34 32
 will actually also install Underscore.js and jQuery.js as these are required for Backbone to function correctly.
35 33
 
36 34
 `yeoman install` also supports installing packages using more than just the package name. Namely:
37 35
 
38  
-{% highlight sh %}
39  
-yeoman install jquery
40  
-yeoman install git://github.com/components/jquery.git
41  
-yeoman install components/jquery (same as above)
42  
-yeoman install http://foo.com/jquery.awesome-plugin.js
43  
-yeoman install ./repos/jquery
44  
-{% endhighlight %}
  36
+    yeoman install jquery
  37
+    yeoman install git://github.com/components/jquery.git
  38
+    yeoman install components/jquery (same as above)
  39
+    yeoman install http://foo.com/jquery.awesome-plugin.js
  40
+    yeoman install ./repos/jquery
45 41
 
46 42
 As you can see, packages can be installed by name, Git endpoint, GitHub shorthand, URL or local path. If you install and URL that is a zip or tar file, yeoman will automatically extract the contents of it. When tags are available in the endpoint, you can specify a semver tag to fetch concrete versions:
47 43
 
48  
-{% highlight sh %}
49  
-yeoman install jquery#1.8.1
50  
-yeoman install git://github.com/components/jquery.git#~1.8.1
51  
-yeoman install components/jquery#1.8.x
52  
-{% endhighlight %}
  44
+    yeoman install jquery#1.8.1
  45
+    yeoman install git://github.com/components/jquery.git#~1.8.1
  46
+    yeoman install components/jquery#1.8.x
53 47
 
54 48
 More in the [Bower docs](https://github.com/twitter/bower/blob/master/README.md#usage)
6  docs/cli/commands/list.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#list" name="list">list</a>
4 2
 
5 3
 Usage: `yeoman list`
@@ -8,7 +6,7 @@ Lists all of the packages that have been installed using `yeoman install` (Bower
8 6
 
9 7
 Example:
10 8
 
11  
-{% highlight sh %}
  9
+```sh
12 10
 # If you have previously called
13 11
 yeoman install backbone
14 12
 
@@ -23,6 +21,6 @@ yeoman list
23 21
 │ └── underscore#1.3.3
24 22
 ├── jquery#1.7.2
25 23
 └── underscore#1.3.3
26  
-{% endhighlight %}
  24
+```
27 25
 
28 26
 As you can see, this also includes the version information for each package and its dependencies.
6  docs/cli/commands/lookup.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#lookup" name="lookup">lookup</a>
4 2
 
5 3
 Usage: `yeoman lookup <packageName>`
@@ -8,10 +6,10 @@ Performs a lookup in the Bower registry for a package of a specific name. One wo
8 6
 
9 7
 Example:
10 8
 
11  
-{% highlight sh %}
  9
+```sh
12 10
 yeoman lookup jquery
13 11
 
14 12
 # outputs
15 13
 
16 14
 jquery git://github.com/maccman/package-jquery.git
17  
-{% endhighlight %}
  15
+```
7  docs/cli/commands/search.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#search" name="search">search</a>
4 2
 
5 3
 Usage: `yeoman search <keyword>`
@@ -8,7 +6,7 @@ Searches the Bower registry for packages which include a specific keyword in the
8 6
 
9 7
 Example:
10 8
 
11  
-{% highlight sh %}
  9
+```sh
12 10
 yeoman search jquery
13 11
 
14 12
 # outputs
@@ -18,5 +16,4 @@ Search results:
18 16
   - jquery git://github.com/maccman/package-jquery.git
19 17
   - jquery-ui git://github.com/maccman/package-jquery-ui.git
20 18
   - jquery-infinite-scroll git://github.com/paulirish/infinite-scroll.git
21  
-
22  
-{% endhighlight %}
  19
+```
2  docs/cli/commands/server.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#server" name="server">server</a>
4 2
 
5 3
 Usage: `yeoman server`
6  docs/cli/commands/test.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#test" name="test">test</a>
4 2
 
5 3
 Usage: `yeoman test`
@@ -18,7 +16,7 @@ launched to serve file for PhantomJS.
18 16
 
19 17
 Example:
20 18
 
21  
-{% highlight sh %}
  19
+```sh
22 20
 yeoman test
23 21
 
24 22
 # outputs:
@@ -29,4 +27,4 @@ Running specs for index.html
29 27
 >> 82 assertions passed in 53 specs (562ms)
30 28
 
31 29
 Done, without errors.
32  
-{% endhighlight %}
  30
+```
12  docs/cli/commands/uninstall.md
Source Rendered
... ...
@@ -1,4 +1,3 @@
1  
-
2 1
 ## <a href="#uninstall" name="uninstall">uninstall</a>
3 2
 
4 3
 Usage: yeoman uninstall packageName
@@ -7,24 +6,23 @@ Removes the package `packageName` from the current project.
7 6
 
8 7
 Example:
9 8
 
10  
-{% highlight sh %}
  9
+```sh
11 10
 yeoman uninstall backbone
12 11
 
13 12
 # outputs:
14 13
 
15 14
 bower uninstalling /project/components/backbone
16  
-{% endhighlight %}
  15
+```
17 16
 
18  
-Note: If you attempt to uninstall a package that is a dependency of other packages, yeoman (via Bower)
19  
-will throw an error.
  17
+Note: If you attempt to uninstall a package that is a dependency of other packages, yeoman (via Bower) will throw an error.
20 18
 
21 19
 Example:
22 20
 
23  
-{% highlight sh %}
  21
+```sh
24 22
 yeoman uninstall jquery
25 23
 
26 24
 # outputs:
27 25
 warning backbone depends on jquery
28  
-{% endhighlight %}
  26
+```
29 27
 
30 28
 This simply means that you should uninstall backbone (the top-level package with the dependency) if you wish to remove all traces of the jquery package.
6  docs/cli/commands/update.md
Source Rendered
... ...
@@ -1,5 +1,3 @@
1  
-
2  
-
3 1
 ## <a href="#update" name="update">update</a>
4 2
 
5 3
 Usage: `yeoman update <packageName>`
@@ -8,11 +6,11 @@ Updates an already installed package `packageName` to the latest version availab
8 6
 
9 7
 Example:
10 8
 
11  
-{% highlight sh %}
  9
+```sh
12 10
 yeoman update jquery
13 11
 
14 12
 # outputs
15 13
 bower checking out jquery#v1.7.2
16  
-{% endhighlight %}
  14
+```
17 15
 
18 16
 The `update` command will also update any other packages in your project relying on this dependency to use this most recent version if any update is applied.
174  docs/cli/generators.md
Source Rendered
@@ -95,20 +95,22 @@ Generators are built on top of Grunt. Grunt provides powerful options parsing an
95 95
 The first step is to create a file at `lib/generators/initializer/index.js with
96 96
 the following content:
97 97
 
98  
-    var util = require('util'),
99  
-        yeoman = require('../../../');
  98
+```js
  99
+var util = require('util'),
  100
+    yeoman = require('../../../');
100 101
 
101  
-    module.exports = Generator;
  102
+module.exports = Generator;
102 103
 
103  
-    function Generator() {
104  
-      yeoman.generators.Base.apply(this, arguments);
105  
-    }
  104
+function Generator() {
  105
+  yeoman.generators.Base.apply(this, arguments);
  106
+}
106 107
 
107  
-    util.inherits(Generator, yeoman.generators.Base);
  108
+util.inherits(Generator, yeoman.generators.Base);
108 109
 
109  
-    Generator.prototype.createInitializerFile = function() {
110  
-      this.write('app/js/initializer.js', "// Add initialization content here\n");
111  
-    };
  110
+Generator.prototype.createInitializerFile = function() {
  111
+  this.write('app/js/initializer.js', "// Add initialization content here\n");
  112
+};
  113
+```
112 114
 
113 115
 `write` is a method provided by `yeoman.generators.Base`, and is a basic facade to the `grunt.file` API. When we "write" things, this happen relative to the working directory (that is the Gruntfile location, the Gruntfile is resolved internally, walking up the FS until one is found. This is most likely the root
114 116
 of the yeoman application).
@@ -154,22 +156,24 @@ Before we go on, let’s see our brand new generator description:
154 156
 
155 157
 Yeoman is usually able to generate good descriptions, but not in this particular case. We can solve this problem in two ways. The first one is calling desc inside our generator:
156 158
 
157  
-    var util = require('util'),
158  
-        yeoman = require('../../../');
  159
+```js
  160
+var util = require('util'),
  161
+    yeoman = require('../../../');
159 162
 
160  
-    module.exports = Generator;
  163
+module.exports = Generator;
161 164
 
162  
-    function Generator() {
163  
-      yeoman.generators.Base.apply(this, arguments);
  165
+function Generator() {
  166
+  yeoman.generators.Base.apply(this, arguments);
164 167
 
165  
-      this.desc('This generator creates an initializer file at app/js/');
166  
-    }
  168
+  this.desc('This generator creates an initializer file at app/js/');
  169
+}
167 170
 
168  
-    util.inherits(Generator, yeoman.generators.Base);
  171
+util.inherits(Generator, yeoman.generators.Base);
169 172
 
170  
-    Generator.prototype.createInitializerFile = function() {
171  
-      this.write('app/js/initializer.js', "// Add initialization content here");
172  
-    };
  173
+Generator.prototype.createInitializerFile = function() {
  174
+  this.write('app/js/initializer.js', "// Add initialization content here");
  175
+};
  176
+```
173 177
 
174 178
 Now we can see the new description by invoking --help on the new generator. The second way to add a description is by creating a file named `USAGE` in the same directory as our generator. We are going to do that in the next step.
175 179
 
@@ -185,18 +189,20 @@ Generators themselves have a generator:
185 189
 
186 190
 This is the generator just created:
187 191
 
188  
-    var util = require('util'),
189  
-        yeoman = require('../../../');
  192
+```js
  193
+var util = require('util'),
  194
+    yeoman = require('../../../');
190 195
 
191  
-    module.exports = Generator;
  196
+module.exports = Generator;
192 197
 
193  
-    function Generator() {
194  
-      yeoman.generators.NamedBase.apply(this, arguments);
  198
+function Generator() {
  199
+  yeoman.generators.NamedBase.apply(this, arguments);
195 200
 
196  
-      this.sourceRoot(__dirname, 'templates');
197  
-    }
  201
+  this.sourceRoot(__dirname, 'templates');
  202
+}
198 203
 
199  
-    util.inherits(Generator, yeoman.generatos.NamedBase);
  204
+util.inherits(Generator, yeoman.generatos.NamedBase);
  205
+```
200 206
 
201 207
 First, notice that we are inheriting from `yeoman.Generators.NamedBase` instead of `yeoman.Generators.Base`. This means that our generator expects at least one argument, which will be the name of the initializer, and will be available in our code in the variable `name`.
202 208
 
@@ -220,21 +226,23 @@ lib/generators/initializer/templates/initializer.js with the following content:
220 226
 
221 227
 And now let’s change the generator to copy this template when invoked:
222 228
 
223  
-    var util = require('util'),
224  
-        yeoman = require('yeoman');
  229
+```js
  230
+var util = require('util'),
  231
+    yeoman = require('yeoman');
225 232
 
226  
-    module.exports = Generator;
  233
+module.exports = Generator;
227 234
 
228  
-    function Generator() {
229  
-      yeoman.generators.NamedBase.apply(this, arguments);
230  
-      // if your templates/ location differ, feel free to set it with sourceRoot()
231  
-    }
  235
+function Generator() {
  236
+  yeoman.generators.NamedBase.apply(this, arguments);
  237
+  // if your templates/ location differ, feel free to set it with sourceRoot()
  238
+}
232 239
 
233  
-    util.inherits(Generator, yeoman.generatos.NamedBase);
  240
+util.inherits(Generator, yeoman.generatos.NamedBase);
234 241
 
235  
-    Generator.prototype.copyInitializerFile = function() {
236  
-      this.copy('initializer.js', 'config/initializers/' + this.name + '.js');
237  
-    };
  242
+Generator.prototype.copyInitializerFile = function() {
  243
+  this.copy('initializer.js', 'config/initializers/' + this.name + '.js');
  244
+};
  245
+```
238 246
 
239 247
 And let’s execute our generator:
240 248
 
@@ -282,15 +290,17 @@ If none is found you get an error message.
282 290
 Yeoman own generators are flexible enough to let you customize scaffolding. They
283 291
 can be configured in your application Gruntfile, these are some defaults:
284 292
 
285  
-      generators: {
286  
-        'template-engine': 'handlebars',
287  
-        'test-framework': {
288  
-          name: 'mocha',
289  
-          options: {
290  
-            ui: 'bdd'
291  
-          }
292  
-        }
293  
-      }
  293
+```js
  294
+generators: {
  295
+  'template-engine': 'handlebars',
  296
+  'test-framework': {
  297
+    name: 'mocha',
  298
+    options: {
  299
+      ui: 'bdd'
  300
+    }
  301
+  }
  302
+}
  303
+```
294 304
 
295 305
 Looking at this output, it’s easy to understand how generators work in yeoman.
296 306
 
@@ -317,7 +327,7 @@ If you generate another resource, you can see that we get exactly the same resul
317 327
 
318 328
 So we know that a typical generator looks like the following:
319 329
 
320  
-{% highlight js %}
  330
+```js
321 331
 var util = require('util'),
322 332
     yeoman = require('../../../');
323 333
 
@@ -334,11 +344,11 @@ Generator.prototype.createSomething = function() {
334 344
 };
335 345
 
336 346
 // ... other methods ...
337  
-{% endhighlight %}
  347
+```
338 348
 
339 349
 Generators can also be written in CoffeeScript, they just needs to be named with a `.coffee` extension (typically `lib/generators/generatorName/index.coffee`)
340 350
 
341  
-{% highlight coffee %}
  351
+```coffee
342 352
 yeoman = require 'yeoman'
343 353
 
344 354
 module.exports = class Generator extends yeoman.generators.NamedBase
@@ -350,7 +360,7 @@ module.exports = class Generator extends yeoman.generators.NamedBase
350 360
     # code
351 361
 
352 362
   # ... other method ...
353  
-{% endhighlight %}
  363
+```
354 364
 
355 365
 They're usually layout like so:
356 366
 
@@ -389,12 +399,12 @@ In addition to the grunt.file API directly available into your generators, you
389 399
 can use the [grunt.log](https://github.com/gruntjs/grunt/blob/master/docs/api_log.md#the-log-api) API as `this.log`
390 400
 
391 401
 
392  
-{% highlight js %}
  402
+```js
393 403
 Generator.prototype.doingSomething = function() {
394  
-  this.log.writeln("I\m doing something");
395  
-  this.log.ok(".. And I think it's ok ..");
  404
+  this.log.writeln('I\'m doing something');
  405
+  this.log.ok('.. And I think it's ok ..'');
396 406
 };
397  
-{% endhighlight %}
  407
+```
398 408
 
399 409
 sync vs async
400 410
 -------------
@@ -483,13 +493,13 @@ Must be called within the constructor only.
483 493
 
484 494
 Register a hook to invoke a generator based on the value supplied by the user to the given option named "name". An option is created when this method is invoked and you can set a hash to customize it.
485 495
 
486  
-{% highlight js %}
  496
+```js
487 497
 function MyGenerator(args, options, config) {
488 498
   yeoman.generators.Base.apply(this, arguments);
489 499
   // init a framework specific controller
490 500
   this.hookFor('js-framework');
491 501
 }
492  
-{% endhighlight %}
  502
+```
493 503
 
494 504
 Hooks work in a way that you can delegate the groundwork of scaffolding to other generators. They're totally inspired by Rails 3 generators [`hook_for` method](http://apidock.com/rails/Rails/Generators/Base/hook_for/class).
495 505
 
@@ -506,13 +516,13 @@ The controller generator will then try to invoke the following generators:
506 516
 
507 517
 Notice that the value of a given hook can be defined in your application Gruntfile as well:
508 518
 
509  
-{% highlight js %}
  519
+```js
510 520
 // grunt config
511 521
 generators: {
512 522
   'js-framework': 'backbone'
513 523
 }
514 524
 // ... more grunt config ...
515  
-{% endhighlight %}
  525
+```
516 526
 
517 527
 This is what allows any js framework to hook into Yeoman as long as it provides any of the hooks above.
518 528
 
@@ -527,10 +537,10 @@ The first and last part used to find the generator to be invoked are guessed bas
527 537
 
528 538
 Let’s suppose you are creating a generator that needs to invoke the controller generator from a unit test. Your first attempt is:
529 539
 
530  
-{% highlight js %}
  540
+```js
531 541
 // in lib/generators/awesome/index.js generator's constructor.
532 542
 this.hookFor('test-framework');
533  
-{% endhighlight %}
  543
+```
534 544
 
535 545
 The lookup in this case for test_unit as input is:
536 546
 
@@ -541,10 +551,11 @@ for `test-framework` hook)
541 551
 
542 552
 Which is not the desired lookup. You can change it by providing the `as` option:
543 553
 
544  
-{% highlight js %}
  554
+```js
545 555
 // in lib/generators/awesome/index.js generator's constructor.
546 556
 this.hookFor('test-framework', { as: 'controller' });
547  
-{% endhighlight %}
  557
+```
  558
+
548 559
 And now it will lookup at:
549 560
 
550 561
     "test_framework:controller", "test_framework"
@@ -555,11 +566,11 @@ And now it will lookup at:
555 566
 
556 567
 Grunt's [`grunt.file.copy`](https://github.com/gruntjs/grunt/blob/master/docs/api_file.md#grunt-file-copy) is used, we simply make sure that relative path are prefixed by the generator's `sourceRoot` value.
557 568
 
558  
-{% highlight js %}
  569
+```js
559 570
 // similar to
560 571
 var source = path.join(this.sourceRoot(), 'path/to/file.js');
561 572
 grunt.file.copy(source, destination, options);
562  
-{% endhighlight %}
  573
+```
563 574
 
564 575
 ### generator.read(filepath, [encoding])
565 576
 
@@ -574,37 +585,38 @@ Just like
574 585
 [`grunt.file.write`](https://github.com/gruntjs/grunt/blob/master/docs/api_file.md#grunt-file-write),
575 586
 we simply ensure the log output of the files being written.
576 587
 
577  
-{% highlight js %}
  588
+```js
578 589
 // similar to
579 590
 grunt.option('verbose', true);
580 591
 grunt.file.write(filepath, encoding);
581 592
 grunt.option('verbose', false);
582  
-{% endhighlight %}
  593
+```
583 594
 
584 595
 ### generator.template(source, [destination], [data])
585 596
 
586 597
 Gets an underscore template at the relative source, executes it and makes a copy at the relative destination. If the destination is not given it's assumed to be equal to the source relative to destination.
587 598
 
588  
-{% highlight js %}
  599
+```js
589 600
 this.template('Gruntfile.js');
590  
-{% endhighlight %}
  601
+```
591 602
 
592 603
 will copy and process the `templates/Gruntfile.js` file through `grunt.template.process`, and write the results to `./Gruntfile.js` relative the the application root.
593 604
 
594 605
 Another example is using a `templates/model.js` template to write at the `app/js/models/{name}-model.js` location in a `NamedBase` generator.
595 606
 
596  
-{% highlight js %}
  607
+```js
597 608
 this.template('model.js', path.join('app/js/models', this.name + '-model.js'));
598  
-{% endhighlight %}
  609
+```
  610
+
599 611
 ### generator.directory(source, [destination])
600 612
 
601 613
 Copies recursively the files from source directory to destination root directory. If the destination is not given it's assumed to be equal to the source relative to destination.
602 614
 
603 615
 Each file is copied and processed through `grunt.template.process`.
604 616
 
605  
-{% highlight js %}
  617
+```js
606 618
 this.directory('.', 'test');
607  
-{% endhighlight %}
  619
+```
608 620
 
609 621
 The example above copies and process any files within generators `templates/`
610 622
 directory, and write them at the `test/` location.
@@ -613,17 +625,17 @@ directory, and write them at the `test/` location.
613 625
 
614 626
 Fetch a remote tarball, and untar at the given destination.
615 627
 
616  
-{% highlight js %}
  628
+```js
617 629
 this.tarball('https://github.com/twitter/bootstrap/tarball/master', 'vendor/bootstrap', this.async());
618  
-{% endhighlight %}
  630
+```
619 631
 
620 632
 ### generator.fetch(url, destination, cb)
621 633
 
622 634
 Download a single file at the given destination.
623 635
 
624  
-{% highlight js %}
  636
+```js
625 637
 this.fetch('http://zeptojs.com/zepto.js', 'js/vendor/zepto.js', this.async());
626  
-{% endhighlight %}
  638
+```
627 639
 
628 640
 ### generator.remote(username, repository, [branch], cb)
629 641
 
@@ -639,7 +651,7 @@ the main API to interact with downloaded package.
639 651
 The example below downloads and cache the html5-boilerplate project, and use the `remote` object
640 652
 to copy the whole project into the `app/` folder.
641 653
 
642  
-{% highlight js %}
  654
+```js
643 655
 var cb = this.async();
644 656
 this.remote('h5bp', 'html5-boilerplate', 'master', function(err, remote) {
645 657
   if(err) return cb(err);
@@ -648,7 +660,7 @@ this.remote('h5bp', 'html5-boilerplate', 'master', function(err, remote) {
648 660
   remote.directory('.', 'app');
649 661
   cb();
650 662
 });
651  
-{% endhighlight %}
  663
+```
652 664
 
653 665
 `remote()` allows the download of full repositories and copying of single or
654 666
 multiple files. `remote` object is your API to access this fetched (and cached)
113  docs/cli/modules.md
Source Rendered
... ...
@@ -1,4 +1,3 @@
1  
-
2 1
 ## <a href="#modules" name="modules">EcmaScript 6 Modules And Module Support</a>
3 2
 
4 3
 Note: This content is subject to change and may be removed prior to launch.
@@ -10,41 +9,41 @@ Yeoman comes with experimental support for ES6 modules, made possible through Re
10 9
 
11 10
 Also note that as Require HM is a RequireJS plugin, ES6 modules are only supported when used with RequireJS. We hope to change this in the future once support for ES6 modules in Google Traceur has improved.*
12 11
 
13  
-###module:
  12
+### module:
14 13
 
15 14
 In ES6, A module is a unit of code contained within a `module` declaration. It can either be defined inline or within an externally loaded module file. A skeleton inline module for a Car could be written:
16 15
 
17  
-{% highlight javascript %}
  16
+```js
18 17
 module Car{
19 18
   // import …
20 19
   // export …
21 20
 }
22  
-{% endhighlight %}
  21
+```
  22
+
23 23
 When we say *externally loaded modules*, we are referring to modules which are either loaded using `import` declarations or the Module Loader API. Both will be covered shortly.
24 24
 
25 25
 A module *instance* is a module which has been evaluated, is linked to other modules or has lexically encapsulated data. Examples of modules instances are:
26 26
 
27  
-{% highlight javascript %}
  27
+```js
28 28
 module myCar = Car;
29 29
 module myCar at "car.js";
30  
-{% endhighlight %}
  30
+```
31 31
 
32 32
 `module` declarations can be used in the following contexts:
33 33
 
34  
-{% highlight javascript %}
  34
+```js
35 35
 module Universe {}
36 36
 module Universe { module MilkyWay {} }
37 37
 module MilkyWay = "Universe/MilkyWay"
38 38
 module System = Universe.MilkyWay.SolarSystem
39 39
 module System = SolarSystem
  40
+```
40 41
 
41  
-{% endhighlight %}
42  
-
43  
-###export:
  42
+### export:
44 43
 
45 44
 An export declaration declares that a local function or variable binding is visible externally to other modules. If familiar with the module pattern, think of this concept as being parallel to the idea of exposing functionality publicly.
46 45
 
47  
-{% highlight javascript %}
  46
+```js
48 47
 module Car{
49 48
 
50 49
   // Internals
@@ -58,24 +57,23 @@ module Car{
58 57
   export var miles = 5000;
59 58
   export var color = "silver";
60 59
 }
61  
-
62  
-{% endhighlight %}
  60
+```
63 61
 
64 62
 Modules `import` what they wish to use from other modules. Other modules may read the module exports (e.g `drive()`, `miles` etc. above) but they cannot modify them. Exports can be renamed as well so their names are different from local names.
65 63
 
66 64
 A module may also export other modules for consumption.
67 65
 
68  
-{% highlight javascript %}
  66
+```js
69 67
 module Car{
70 68
   export module engine{}
71 69
   export module driver{}
72 70
   export module seats{}
73 71
 }
74  
-{% endhighlight %}
  72
+```
75 73
 
76 74
 `export` can be used in the following contexts:
77 75
 
78  
-{% highlight javascript %}
  76
+```js
79 77
 export var document
80 78
 export var document = { }
81 79
 export function parse() { }
@@ -84,14 +82,13 @@ export SolarSystem
84 82
 export Mercury, Venus, Earth
85 83
 export * from SolarSystem
86 84
 export { Mercury: SolarSystem.Mercury, Earth: SolarSystem.Earth }
87  
-{% endhighlight %}
  85
+```
88 86
 
89  
-
90  
-###import:
  87
+### import:
91 88
 
92 89
 An import declaration binds another modules exports as local variables. Variables that are imported can be locally renamed to avoid naming conflicts.
93 90
 
94  
-{% highlight javascript %}
  91
+```js
95 92
 module Car{
96 93
   export function drive(speed, direction){
97 94
     console.log('details:', speed, direction);
@@ -105,59 +102,58 @@ module Car{
105 102
   export var color = "silver";
106 103
 
107 104
 };
108  
-{% endhighlight %}
  105
+```
109 106
 
110 107
 Revisiting the export example above, we can now selectively choose what we wish to `import` when in another module.
111 108
 
112 109
 We can just import `drive()`:
113 110
 
114  
-{% highlight javascript %}
  111
+```js
115 112
 import drive from Car;
116  
-{% endhighlight %}
  113
+```
117 114
 
118 115
 We can import `drive()` and `miles`:
119 116
 
120  
-{% highlight javascript %}
  117
+```js
121 118
 import {drive, miles} from Car;
122  
-{% endhighlight %}
  119
+```
123 120
 
124 121
 We can import `check()` from our engine module:
125 122
 
126  
-{% highlight javascript %}
  123
+```js
127 124
 import check from Car.engine;
128  
-{% endhighlight %}
  125
+```
129 126
 
130 127
 We can import all of the exports:
131 128
 
132  
-{% highlight javascript %}
  129
+```js
133 130
 import * from Car;
134  
-{% endhighlight %}
  131
+```
135 132
 
136 133
 We can also import an entire file as a module:
137 134
 
138  
-{% highlight javascript %}
  135
+```js
139 136
 import "car.js" as Car;
140  
-{% endhighlight %}
  137
+```
141 138
 
142 139
 Or import `drive()` without needing to bind the module to a local name:
143 140
 
144  
-{% highlight javascript %}
  141
+```js
145 142
 import drive from "car.js";
146  
-{% endhighlight %}
  143
+```
147 144
 
148 145
 This similarly works with JavaScript libraries like Underscore.js:
149 146
 
150  
-{% highlight javascript %}
  147
+```js
151 148
 import reduce from "Underscore.js"
152  
-{% endhighlight %}
  149
+```
153 150
 
154 151
 
155 152
 ### module, import and export
156 153
 
157 154
 Bringing these three concepts together:
158 155
 
159  
-
160  
-{% highlight javascript %}
  156
+```js
161 157
 module vehicle{
162 158
   export function drive(speed, direction){
163 159
     console.log('We are driving at a speed of ' + speed + ', ' + direction);
@@ -183,17 +179,16 @@ module premiumExtras{
183 179
     //...
184 180
   }
185 181
 }
  182
+```
186 183
 
187  
-{% endhighlight %}
188  
-
189  
-{% highlight javascript %}
  184
+```js
190 185
 // Engine.js
191 186
 module engine{
192 187
 
193 188
 }
194  
-{% endhighlight %}
  189
+```
195 190
 
196  
-{% highlight javascript %}
  191
+```js
197 192
 module Car{
198 193
   import * from vehicle;
199 194
   import {specialRims, mp3Player} from basicExtras;
@@ -203,7 +198,7 @@ module Car{
203 198
   export drive;
204 199
   export stop;
205 200
 }
206  
-{% endhighlight %}
  201
+```
207 202
 
208 203
 -- how do you rename exports?
209 204
 
@@ -213,7 +208,7 @@ module Car{
213 208
 
214 209
 Earlier, we mentioned the concept of a Module Loader API. The module loader allows us to dynamically load in scripts for consumption. Similar to `import`, we are able to consume anything defined as an `export` from such modules.
215 210
 
216  
-{% highlight javascript %}
  211
+```js
217 212
 // Signature: load( moduleURL, callback, errorCallback )
218 213
 
219 214
 Loader.load("car.js", function(car) {
@@ -221,8 +216,7 @@ Loader.load("car.js", function(car) {
221 216
     }, function(err){
222 217
         console.log("Error:" + err);
223 218
     });
224  
-
225  
-{% endhighlight %}
  219
+```
226 220
 
227 221
 `load()` accepts three arguments:
228 222
 
@@ -232,8 +226,7 @@ Loader.load("car.js", function(car) {
232 226
 
233 227
 Whilst the above example seems fairly trivial to use, the Loader API is there to provide a way to load modules in controlled contexts and actually supports a number of different configuration options. `Loader` itself is a system provided instance of the API, but it's possible to create custom loaders using the `Loader` constructor.
234 228
 
235  
-
236  
-{% highlight javascript %}
  229
+```js
237 230
 // The Loader constructor creates a new loader
238 231
 var customLoader = new Loader(
239 232
     // Define the parent of this loader
@@ -264,8 +257,7 @@ var customLoader = new Loader(
264 257
     // A hook for source translation
265 258
     translate: function( src, relativeURL, baseURL, resolved ){…}
266 259
 });
267  
-{% endhighlight %}
268  
-
  260
+```
269 261
 
270 262
 Let's review the final three hooks in more detail:
271 263
 
@@ -276,7 +268,7 @@ Once a module is resolved, it must be fetched. The `fetch` hook allows us to fet
276 268
 
277 269
 The `fetch` request object has three callbacks:
278 270
 
279  
-{% highlight javascript %}
  271
+```js
280 272
 request = {
281 273
 
282 274
   // callbacks for the loading hook
@@ -290,7 +282,7 @@ request = {
290 282
   // callback to indicate am error occurred in the loading
291 283
   reject: function( msg )
292 284
 }
293  
-{% endhighlight %}
  285
+```
294 286
 
295 287
 If we don't supply a `fetch` hook, the parent Loader's `fetch` is used instead.
296 288
 
@@ -307,7 +299,7 @@ When code is evaluated, we have the option of translating the source of that cod
307 299
 
308 300
 A complete custom loader example could thus be written as follows:
309 301
 
310  
-{% highlight javascript %}
  302
+```js
311 303
 var customLoader = new Loader(Loader,{
312 304
     global: window,
313 305
     baseURL: document.URL.substring(0, document.URL.lastIndexOf('\/') + 1),
@@ -335,7 +327,7 @@ var customLoader = new Loader(Loader,{
335 327
       return src;
336 328
     }
337 329
   });
338  
-{% endhighlight %}
  330
+```
339 331
 
340 332
 
341 333
 *Note: As Require HM is able to work with the RequireJS `define()` and `require()` syntax, it doesn't currently support the Module Loader API. If one is however required, there is a shim available for this feature [here](https://github.com/addyosmani/es6-module-loader/).*
@@ -345,7 +337,7 @@ var customLoader = new Loader(Loader,{
345 337
 
346 338
 We can also define modules with a shared state:
347 339
 
348  
-{% highlight javascript %}
  340
+```js
349 341
 module Car{
350 342
   export module milesCounter {
351 343
       var miles = 0;
@@ -353,11 +345,11 @@ module Car{
353 345
       export function currentMiles() { return miles }
354 346
   };
355 347
 };
356  
-{% endhighlight %}
  348
+```
357 349
 
358 350
 or cyclic dependencies:
359 351
 
360  
-{% highlight javascript %}
  352
+```js
361 353
 module Car {
362 354
     import * from Scooter;
363 355
     export function even(n) {
@@ -371,11 +363,6 @@ module Scooter {
371 363
         return n != 0 && even(n - 1);
372 364
     }
373 365
 }
374  
-{% endhighlight %}
375  
-
  366
+```
376 367
 
377 368
 *Note: Require HM does not presently support cyclic dependencies. We are working on fixing this limitation.*
378  
-
379  
-
380  
-
381  
-
45  docs/cli/package_manager.md
Source Rendered
@@ -7,7 +7,7 @@ Yeoman's integration with [Twitter Bower](http://github.com/twitter/bower) chang
7 7
 In Bower, dependencies are listed in a ‘component.json’ file, similar to Node’s package.json or the Ruby Gemfile. This is useful for locking down the dependencies a project has.
8 8
 
9 9
 
10  
-{% highlight json %}
  10
+```json
11 11
 {
12 12
   "name": "myProject",
13 13
   "version": "1.0.0",
@@ -15,15 +15,13 @@ In Bower, dependencies are listed in a ‘component.json’ file, similar to Nod
15 15
     "modernizr": "~2.6.1"
16 16
   }
17 17
 }
18  
-{% endhighlight %}
  18
+```
19 19
 
20  
-Dependencies are then installed locally via the `yeoman install command. First they're resolved to find conflicts, then downloaded and unpacked in a local sub dir called components:
  20
+Dependencies are then installed locally via the `yeoman install` command. First they're resolved to find conflicts, then downloaded and unpacked in a local sub dir called components:
21 21
 
22  
-{% highlight sh %}
23  
-/component.json
24  
-/components/modernizr/index.js
25  
-/components/modernizr/modernizr.js
26  
-{% endhighlight %}
  22
+    /component.json
  23
+    /components/modernizr/index.js
  24
+    /components/modernizr/modernizr.js
27 25
 
28 26
 This approach has a number of benefits.
29 27
 
@@ -35,42 +33,34 @@ This approach has a number of benefits.
35 33
 
36 34
 The easiest approach is to use a Bower package statically is to then just reference the package manually from a script tag:
37 35
 
38  
-{% highlight sh %}
  36
+```html
39 37
 <script src="components/modernizr/modernizr.js"></script>
40  
-{% endhighlight %}
  38
+```
41 39
 
42 40
 Similar to NPM, our Bower integration also allows users to easily search for and update packages easily. e.g
43 41
 
44 42
 To search for a package:
45 43
 
46  
-{% highlight sh %}
47  
-yeoman search jquery
48  
-{% endhighlight %}
  44
+    yeoman search jquery
49 45
 
50 46
 To install a package:
51 47
 
52  
-{% highlight sh %}