Skip to content
Browse files

Updating docs - replacing backticks with pygment format

  • Loading branch information...
1 parent 41d299c commit f14be7d3d207ebb36f2842ffe2957862b2ffb123 @ericduran ericduran committed Sep 10, 2012
View
10 docs/cli/commands/build.md
@@ -6,7 +6,7 @@ Usage: `yeoman build`, `yeoman build:<target>`
Constructs an optimized version of your application that's ready to deploy.
-Yeoman makes use of [Grunt](https://github.com/cowboy/grunt) behind the scenes to tackle much of the hard work for this, with some useful additions that assist with compression, optimization and testing.
+Yeoman makes use of [Grunt](https://github.com/cowboy/grunt) behind the scenes to tackle much of the hard work for this, with some useful additions that assist with compression, optimization and testing.
These include:
@@ -61,9 +61,9 @@ You can either do this at a project level by editing your projects Gruntfile or
at a generator level if you would rather avoid editing the Gruntfile outside of the default
setup each time.
-The following is the relevant block to edit within your Gruntfile:
+The following is the relevant block to edit within your Gruntfile:
-```javascript
+{% highlight javascript %}
// rjs configuration. You don't necessarily need to specify the typical
// `path` configuration, the rjs task will parse these values from your
// main module, using http://requirejs.org/docs/optimization.html#mainConfigFile
@@ -77,9 +77,9 @@ The following is the relevant block to edit within your Gruntfile:
baseUrl: './scripts',
wrap: true
}
-```
+{% endhighlight %}
-See the official project [repo](https://github.com/jrburke/r.js) for more information on the
+See the official project [repo](https://github.com/jrburke/r.js) for more information on the
options supported by r.js.
View
6 docs/cli/commands/help.md
@@ -5,7 +5,7 @@
Lists out the commands and tasks supported by yeoman and should print out the following to the console:
-```shell
+{% highlight shell %}
yeoman init # Initialize and scaffold a new project using generator templates
yeoman build # Build an optimized version of your app, ready to deploy
yeoman server # Launch a preview server which will begin watching for changes
@@ -17,6 +17,6 @@ yeoman update # Update a package to the latest version
yeoman list # List the packages currently installed
yeoman search # Query the registry for matching package names
yeoman lookup # Look up info on a particular package
-```
+{% endhighlight %}
-Note that commands may also support additional flags and so we recommend consulting the documentation for specific commands for the complete details.
+Note that commands may also support additional flags and so we recommend consulting the documentation for specific commands for the complete details.
View
40 docs/cli/commands/init.md
@@ -18,7 +18,7 @@ By default we support Compass and CoffeeScript, so if your project includes any
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:
-```shell
+{% highlight shell %}
_ .--------------------------.
_|o|_ | Welcome to Yeoman, |
@@ -34,71 +34,71 @@ Out of the box I include HTML5 Boilerplate, jQuery and Modernizr.
Please answer the following:
[?] Would you like to include Twitter Bootstrap for Compass? (Y/n)
-```
+{% endhighlight %}
### custom generators
Some of our supported custom generators include:
-```shell
+{% highlight shell %}
yeoman init bbb #backbone boilerplate
yeoman init angular #angularjs seed
yeoman init ember #ember app based on ember-rails
-```
+{% endhighlight %}
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:
-```shell
+{% highlight shell %}
yeoman init generatorName #e.g yeoman init angular
-```
+{% endhighlight %}
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:
-```shell
+{% highlight shell %}
yeoman init angular:all
-```
+{% endhighlight %}
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.
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:
-```shell
+{% highlight shell %}
yeoman init angular
-```
+{% endhighlight %}
and has it defer to `angular:all` automatically.
If one then wishes to create further AngularJS controllers, one can simply call the 'controller' sub-generator as follows:
-```shell
+{% highlight shell %}
yeoman init angularjs:controller controllerName
-```
+{% endhighlight %}
where `controllerName` is the name of the Controller you wish to create.
Similarly, a Backbone.js Generator may be used as follows:
-```shell
+{% highlight shell %}
yeoman init backbone
-```
+{% endhighlight %}
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:
-```shell
+{% highlight shell %}
yeoman init backbone:model modelName
yeoman init backbone:collection collectionName
yeoman init backbone:view viewName
yeoman init backbone:router routerName
-```
+{% endhighlight %}
To list out all of the generators currently available locally, you can use the `--help` flag as follows:
-```shell
+{% highlight shell %}
yeoman init --help
-```
+{% endhighlight %}
This will print out a list of existing generators, including some of the below:
-```shell
+{% highlight shell %}
Please choose a generator below.
Yeoman:
@@ -117,4 +117,4 @@ Backbone:
backbone:router
backbone:view
backbone:collection
-```
+{% endhighlight %}
View
12 docs/cli/commands/install.md
@@ -10,27 +10,27 @@ Running yeoman install packageName will install the dependencies in your project
Example:
-```shell
+{% highlight shell %}
yeoman install jquery
yeoman install jquery spine
-```
+{% endhighlight %}
If installing a dependency which has its own dependencies described, these dependencies will also be pulled in.
Example:
-```shell
+{% highlight shell %}
yeoman install backbone
-```
+{% endhighlight %}
will actually also install Underscore.js and jQuery.js as these are required for Backbone to function correctly.
`yeoman install` also supports installing packages using more than just the package name. Namely:
-```shell
+{% highlight shell %}
bower install jquery
bower install git://github.com/maccman/package-jquery.git
bower install http://code.jquery.com/jquery-1.7.2.js
bower install ./repos/jquery
-```
+{% endhighlight %}
View
6 docs/cli/commands/list.md
@@ -8,7 +8,7 @@ Lists all of the packages that have been installed using `yeoman install` (Bower
Example:
-```shell
+{% highlight shell %}
# If you have previously called
yeoman install backbone
@@ -23,6 +23,6 @@ yeoman list
│ └── underscore#1.3.3
├── jquery#1.7.2
└── underscore#1.3.3
-```
+{% endhighlight %}
-As you can see, this also includes the version information for each package and its dependencies.
+As you can see, this also includes the version information for each package and its dependencies.
View
4 docs/cli/commands/lookup.md
@@ -8,10 +8,10 @@ Performs a lookup in the Bower registry for a package of a specific name. One wo
Example:
-```shell
+{% highlight shell %}
yeoman lookup jquery
# outputs
jquery git://github.com/maccman/package-jquery.git
-```
+{% endhighlight %}
View
4 docs/cli/commands/search.md
@@ -8,7 +8,7 @@ Searches the Bower registry for packages which include a specific keyword in the
Example:
-```shell
+{% highlight shell %}
yeoman search jquery
# outputs
@@ -19,4 +19,4 @@ Search results:
- jquery-ui git://github.com/maccman/package-jquery-ui.git
- jquery-infinite-scroll git://github.com/paulirish/infinite-scroll.git
-```
+{% endhighlight %}
View
4 docs/cli/commands/test.md
@@ -14,7 +14,7 @@ gets called when running `yeoman build`.
Example:
-```shell
+{% highlight shell %}
yeoman test
# outputs:
@@ -25,4 +25,4 @@ Running specs for index.html
>> 82 assertions passed in 53 specs (562ms)
Done, without errors.
-```
+{% endhighlight %}
View
10 docs/cli/commands/uninstall.md
@@ -7,24 +7,24 @@ Removes the package `packageName` from the current project.
Example:
-```shell
+{% highlight shell %}
yeoman uninstall backbone
# outputs:
bower uninstalling /project/components/backbone
-```
+{% endhighlight %}
Note: If you attempt to uninstall a package that is a dependency of other packages, yeoman (via Bower)
will throw an error.
Example:
-```shell
+{% highlight shell %}
yeoman uninstall jquery
# outputs:
warning backbone depends on jquery
-```
+{% endhighlight %}
-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.
+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.
View
4 docs/cli/commands/update.md
@@ -8,11 +8,11 @@ Updates an already installed package `packageName` to the latest version availab
Example:
-```shell
+{% highlight shell %}
yeoman update jquery
# outputs
bower checking out jquery#v1.7.2
-```
+{% endhighlight %}
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.
View
68 docs/cli/generators.md
@@ -1,8 +1,8 @@
## <a href="#generators" name="generators">generators</a>
-Generator templates allow you to scaffold out a project using a custom setup of boilerplates, frameworks and dependencies. The basic application generated when calling `yeoman init` actually uses a generator itself and they can be quite powerful.
+Generator templates allow you to scaffold out a project using a custom setup of boilerplates, frameworks and dependencies. The basic application generated when calling `yeoman init` actually uses a generator itself and they can be quite powerful.
-Some of the generators Yeoman includes out of the box include implementations for Backbone.js, Ember.js and Angular.js. These allow you to not only use complete boilerplates for an application but also scaffold out smaller parts such as Models, Views, Controllers and so on.
+Some of the generators Yeoman includes out of the box include implementations for Backbone.js, Ember.js and Angular.js. These allow you to not only use complete boilerplates for an application but also scaffold out smaller parts such as Models, Views, Controllers and so on.
### Getting Started
@@ -113,7 +113,7 @@ the following content:
`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
of the yeoman application).
-Our new generator is quite simple: it inherits from `yeoman.generators.Base` and has one method definition. Each "public" method in the generator is executed when a generator is invoked (first level method in the prototype chain, eg. `Base` class method are not called).
+Our new generator is quite simple: it inherits from `yeoman.generators.Base` and has one method definition. Each "public" method in the generator is executed when a generator is invoked (first level method in the prototype chain, eg. `Base` class method are not called).
There are two exceptions, generators won't run:
@@ -317,7 +317,7 @@ If you generate another resource, you can see that we get exactly the same resul
So we know that a typical generator looks like the following:
-```js
+{% highlight js %}
var util = require('util'),
yeoman = require('../../../');
@@ -334,11 +334,11 @@ Generator.prototype.createSomething = function() {
};
// ... other methods ...
-```
+{% endhighlight %}
Generators can also be written in CofeeScript, they just needs to be named with a `.coffee` extension (typically `lib/generators/generatorName/index.coffee`)
-```coffee
+{% highlight coffee %}
yeoman = require 'yeoman'
module.exports = class Generator extends yeoman.generators.NamedBase
@@ -350,7 +350,7 @@ module.exports = class Generator extends yeoman.generators.NamedBase
# code
# ... other method ...
-```
+{% endhighlight %}
They're usually layout like so:
@@ -389,12 +389,12 @@ In addition to the grunt.file API directly available into your generators, you
can use the [grunt.log](https://github.com/cowboy/grunt/blob/master/docs/api_log.md#the-log-api) API as `this.log`
-```js
+{% highlight js %}
Generator.prototype.doingSomething = function() {
this.log.writeln("I\m doing something");
this.log.ok(".. And I think it's ok ..");
};
-```
+{% endhighlight %}
sync vs async
-------------
@@ -483,13 +483,13 @@ Must be called within the constructor only.
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.
-```js
+{% highlight js %}
function MyGenerator(args, options, config) {
yeoman.generators.Base.apply(this, arguments);
// init a framework specific controller
this.hookFor('js-framework');
}
-```
+{% endhighlight %}
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).
@@ -506,13 +506,13 @@ The controller generator will then try to invoke the following generators:
Notice that the value of a given hook can be defined in your application Gruntfile as well:
-```js
+{% highlight js %}
// grunt config
generators: {
'js-framework': 'backbone'
}
// ... more grunt config ...
-```
+{% endhighlight %}
This is what allows any js framework to hook into Yeoman as long as it provides any of the hooks above.
@@ -527,10 +527,10 @@ The first and last part used to find the generator to be invoked are guessed bas
Let’s suppose you are creating a generator that needs to invoke the controller generator from a unit test. Your first attempt is:
-```js
+{% highlight js %}
// in lib/generators/awesome/index.js generator's constructor.
this.hookFor('test-framework');
-```
+{% endhighlight %}
The lookup in this case for test_unit as input is:
@@ -541,10 +541,10 @@ for `test-framework` hook)
Which is not the desired lookup. You can change it by providing the `as` option:
-```js
+{% highlight js %}
// in lib/generators/awesome/index.js generator's constructor.
this.hookFor('test-framework', { as: 'controller' });
-```
+{% endhighlight %}
And now it will lookup at:
"test_framework:controller", "test_framework"
@@ -555,11 +555,11 @@ And now it will lookup at:
Grunt's[`grunt.file.copy`](https://github.com/cowboy/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.
-```js
+{% highlight js %}
// similar to
var source = path.join(this.sourceRoot(), 'path/to/file.js');
grunt.file.copy(source, destination, options);
-```
+{% endhighlight %}
### generator.read(filepath, [encoding])
@@ -574,37 +574,37 @@ Just like
[`grunt.file.write`](https://github.com/cowboy/grunt/blob/master/docs/api_file.md#grunt-file-write),
we simply ensure the log output of the files being written.
-```js
+{% highlight js %}
// similar to
grunt.option('verbose', true);
grunt.file.write(filepath, encoding);
grunt.option('verbose', false);
-```
+{% endhighlight %}
### generator.template(source, [destination], [data])
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.
-```js
+{% highlight js %}
this.template('Gruntfile.js');
-```
+{% endhighlight %}
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.
Another example is using a `templates/model.js` template to write at the `app/js/models/{name}-model.js` location in a `NamedBase` generator.
-```js
+{% highlight js %}
this.template('model.js', path.join('app/js/models', this.name + '-model.js'));
-```
+{% endhighlight %}
### generator.directory(source, [destination])
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.
Each file is copied and processed through `grunt.template.process`.
-```js
+{% highlight js %}
this.directory('.', 'test');
-```
+{% endhighlight %}
The example above copies and process any files within generators `templates/`
directory, and write them at the `test/` location.
@@ -613,17 +613,17 @@ directory, and write them at the `test/` location.
Fetch a remote tarball, and untar at the given destination.
-```js
+{% highlight js %}
this.tarball('https://github.com/twitter/bootstrap/tarball/master', 'vendor/bootstrap', this.async());
-```
+{% endhighlight %}
### generator.fetch(url, destination, cb)
Download a single file at the given destination.
-```js
+{% highlight js %}
this.fetch('http://zeptojs.com/zepto.js', 'js/vendor/zepto.js', this.async());
-```
+{% endhighlight %}
### generator.remote(username, repository, [branch], cb)
@@ -639,7 +639,7 @@ the main API to interract with downloaded package.
The example below downloads and cache the html5-boilerplate project, and use the `remote` object
to copy the whole project into the `app/` folder.
-```js
+{% highlight js %}
var cb = this.async();
this.remote('h5bp', 'html5-boilerplate', 'master', function(err, remote) {
if(err) return cb(err);
@@ -648,7 +648,7 @@ this.remote('h5bp', 'html5-boilerplate', 'master', function(err, remote) {
remote.directory('.', 'app');
cb();
});
-```
+{% endhighlight %}
`remote()` allows the download of full repositories and copying of single or
multiple files. `remote` object is your API to access this fetched (anc cached)
@@ -671,7 +671,7 @@ Same as `generator.directory()` but relative `source` is prefixed with the cache
#### Prompt user before overwriting files with `--force`
-Generators also support a `warnOn` method, which allows developers to warn on global paths that are matching those paths or files which the generator is going to generate (e.g `self.warnOn('*')`.
+Generators also support a `warnOn` method, which allows developers to warn on global paths that are matching those paths or files which the generator is going to generate (e.g `self.warnOn('*')`.
Where used, Yeoman will warn the user they if they proceed that a file will be overwritten and they may need to call the generator with the `--force` flag to proceed.
View
92 docs/cli/modules.md
@@ -14,37 +14,37 @@ Also note that as Require HM is a RequireJS plugin, ES6 modules are only support
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:
-```javascript
+{% highlight javascript %}
module Car{
// import …
// export …
}
-```
+{% endhighlight %}
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.
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:
-```javascript
+{% highlight javascript %}
module myCar = Car;
module myCar at "car.js";
-```
+{% endhighlight %}
`module` declarations can be used in the following contexts:
-```javascript
+{% highlight javascript %}
module Universe {}
module Universe { module MilkyWay {} }
module MilkyWay = "Universe/MilkyWay"
module System = Universe.MilkyWay.SolarSystem
module System = SolarSystem
-```
+{% endhighlight %}
###export:
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.
-```javascript
+{% highlight javascript %}
module Car{
// Internals
@@ -59,23 +59,23 @@ module Car{
export var color = "silver";
}
-```
+{% endhighlight %}
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.
A module may also export other modules for consumption.
-```javascript
+{% highlight javascript %}
module Car{
export module engine{}
export module driver{}
export module seats{}
}
-```
+{% endhighlight %}
`export` can be used in the following contexts:
-```javascript
+{% highlight javascript %}
export var document
export var document = { }
export function parse() { }
@@ -84,14 +84,14 @@ export SolarSystem
export Mercury, Venus, Earth
export * from SolarSystem
export { Mercury: SolarSystem.Mercury, Earth: SolarSystem.Earth }
-```
+{% endhighlight %}
###import:
An import declaraction binds another modules exports as local variables. Variables that are imported can be locally renamed to avoid naming conflicts.
-```javascript
+{% highlight javascript %}
module Car{
export function drive(speed, direction){
console.log('details:', speed, direction);
@@ -105,59 +105,59 @@ module Car{
export var color = "silver";
};
-```
+{% endhighlight %}
Revisiting the export example above, we can now selectively choose what we wish to `import` when in another module.
We can just import `drive()`:
-```javascript
+{% highlight javascript %}
import drive from Car;
-```
+{% endhighlight %}
We can import `drive()` and `miles`:
-```javascript
+{% highlight javascript %}
import {drive, miles} from Car;
-```
+{% endhighlight %}
We can import `check()` from our engine module:
-```javascript
+{% highlight javascript %}
import check from Car.engine;
-```
+{% endhighlight %}
We can import all of the exports:
-```javascript
+{% highlight javascript %}
import * from Car;
-```
+{% endhighlight %}
We can also import an entire file as a module:
-```javascript
+{% highlight javascript %}
import "car.js" as Car;
-```
+{% endhighlight %}
Or import `drive()` without needing to bind the module to a local name:
-```javascript
+{% highlight javascript %}
import drive from "car.js";
-```
+{% endhighlight %}
This similarly works with JavaScript libraries like Underscore.js:
-```javascript
+{% highlight javascript %}
import reduce from "Underscore.js"
-```
+{% endhighlight %}
### module, import and export
Bringing these three concepts together:
-```javascript
+{% highlight javascript %}
module vehicle{
export function drive(speed, direction){
console.log('We are driving at a speed of ' + speed + ', ' + direction);
@@ -184,16 +184,16 @@ module premiumExtras{
}
}
-```
+{% endhighlight %}
-```javascript
+{% highlight javascript %}
// Engine.js
module engine{
}
-```
+{% endhighlight %}
-```javascript
+{% highlight javascript %}
module Car{
import * from vehicle;
import {specialRims, mp3Player} from basicExtras;
@@ -203,7 +203,7 @@ module Car{
export drive;
export stop;
}
-```
+{% endhighlight %}
-- how do you rename exports?
@@ -213,7 +213,7 @@ module Car{
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.
-```javascript
+{% highlight javascript %}
// Signature: load( moduleURL, callback, errorCallback )
Loader.load("car.js", function(car) {
@@ -222,7 +222,7 @@ Loader.load("car.js", function(car) {
console.log("Error:" + err);
});
-```
+{% endhighlight %}
`load()` accepts three arguments:
@@ -233,7 +233,7 @@ Loader.load("car.js", function(car) {
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.
-```javascript
+{% highlight javascript %}
// The Loader constructor creates a new loader
var customLoader = new Loader(
// Define the parent of this loader
@@ -264,7 +264,7 @@ var customLoader = new Loader(
// A hook for source translation
translate: function( src, relativeURL, baseURL, resolved ){…}
});
-```
+{% endhighlight %}
Let's review the final three hooks in more detail:
@@ -276,7 +276,7 @@ Once a module is resolved, it must be fetched. The `fetch` hook allows us to fet
The `fetch` request object has three callbacks:
-```javascript
+{% highlight javascript %}
request = {
// callbacks for the loading hook
@@ -290,7 +290,7 @@ request = {
// callback to indicate am error occurred in the loading
reject: function( msg )
}
-```
+{% endhighlight %}
If we don't supply a `fetch` hook, the parent Loader's `fetch` is used instead.
@@ -307,7 +307,7 @@ When code is evaluated, we have the option of translating the source of that cod
A complete custom loader example could thus be written as follows:
-```javascript
+{% highlight javascript %}
var customLoader = new Loader(Loader,{
global: window,
baseURL: document.URL.substring(0, document.URL.lastIndexOf('\/') + 1),
@@ -335,7 +335,7 @@ var customLoader = new Loader(Loader,{
return src;
}
});
-```
+{% endhighlight %}
*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,19 +345,19 @@ var customLoader = new Loader(Loader,{
We can also define modules with a shared state:
-```javascript
+{% highlight javascript %}
module Car{
export module milesCounter {
var miles = 0;
export function addMile() { return miles++ }
export function currentMiles() { return miles }
};
};
-```
+{% endhighlight %}
or cyclic dependencies:
-```javascript
+{% highlight javascript %}
module Car {
import * from Scooter;
export function even(n) {
@@ -371,7 +371,7 @@ module Scooter {
return n != 0 && even(n - 1);
}
}
-```
+{% endhighlight %}
*Note: Require HM does not presently support cyclic dependencies. We are working on fixing this limitation.*
View
29 docs/cli/package_manager.md
@@ -6,23 +6,24 @@ Yeoman's integration with [Twitter Bower](http://github.com/twitter/bower) chang
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.
-```json
+
+{% highlight json %}
{
"name": "myProject",
"version": "1.0.0",
"dependencies": {
"modernizr": "~2.6.1"
}
}
-```
+{% endhighlight %}
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:
-```shell
+{% highlight shell %}
/component.json
/components/modernizr/index.js
/components/modernizr/modernizr.js
-```
+{% endhighlight %}
This approach has a number of benefits.
@@ -34,35 +35,35 @@ This approach has a number of benefits.
The easiest approach is to use a Bower package statically is to then just reference the package manually from a script tag:
-```shell
+{% highlight shell %}
&lt;script src="components/modernizr/modernizr.js"&gt;&lt;/script&gt;
-```
+{% endhighlight %}
Similar to NPM, our Bower integration also allows users to easily search for and update packages easily. e.g
To search for a package:
-```shell
+{% highlight shell %}
yeoman search jquery
-```
+{% endhighlight %}
To install a package:
-```shell
+{% highlight shell %}
yeoman install jquery
-```
+{% endhighlight %}
To update a package, you need to reference it by name:
-```shell
+{% highlight shell %}
yeoman update jquery
-```
+{% endhighlight %}
To list installed packages:
-```shell
+{% highlight shell %}
yeoman list
-```
+{% endhighlight %}
and so on.

0 comments on commit f14be7d

Please sign in to comment.
Something went wrong with that request. Please try again.