mean help can also be used in conjunction with any command to get more information about that particular functionality. For example, try mean help init to see the options for init
```bash
$ mean help [command]
```
### Users
Information can be display for a specific customer via mean user email. Email is required. User roles can be assigned or removed with the --addRole (or -a) and --removeRole (or -r) options, respectively.
For example, the admin role is required to edit tokens.
```bash $ mean userAll of the remaining of the commands must be run from the root folder of your MEAN application.
Contributed MEAN packages can be installed or uninstalled via the CLI. Also, currently installed modules can be viewed with the list command.
Mean packages installed via the installer are found in /node_modules
#### Search To find new packages run the *mean search* command ```bash $ mean search [packagename] ``` `mean search` will return all of the available packages, `mean search [packagename]` will filter the search results. #### Scaffolding To create a new MEAN app, runmean init. Name for the application is optional. If no name is provided, "mean" is used. The MEAN project will be cloned from GitHub into a directory of the application name.
```bash
$ mean init [name]
$ cd [name] && npm install
```
Note: git must be installed for this command to work properly.
### MiscCheck the database connection for a particular environment (e.g. development (default), test, production) and make sure that the meanio command line version is up to date.
```bash $ mean status ```A simple shortcut to open the mean documentation in your default browser.
```bash $ mean docs ``` ## Packages Everything in mean.io is a package and when extending mean with custom functionality make sure you create your own package and do not alter the core packages. The mean.io package system allows developers to create modular code that provides useful tools that other mean developers can use. The packages, when published, are plug-and-play and are used in a way very similar to traditional npm packages. The mean.io package system integrates all the packages into the mean project as if the code was part of mean itself and provides the developers with all the necessary tools required to integrate their package into the host project. There are two types of packages: **Custom Packages** are generated by the mean scaffolder and contain most of your application logic. Custom packages are found in */packages/custom* and can be published as a contrib package for use by other developers. **Contrib Packages** are installed by the mean installer and are found at */packages/contrib*. Contrib packages are "plug and play". ### Core Packages All `Core` packages can be overridden by other packages allowing you to extend and adapt it to fit your specific needs. See `Overriding views` for detailed examples. #### System The "system" package creates the basic pages as well as defines the layout of the site and integrates the menu into the page. The system package also allows us to define things such as rendering engines, static files and routing on the client and server side. #### Users The "users" package creates the database model of the user, provides validation as well as various login and registration features. #### Access The "access" package manages permissions and middleware. It controls the various authentication methods and is dependent on the users package #### Theme The "theme" package adds some basic CSS and other assets such as images and backgrounds #### Articles The "articles" package is typically used as an example starting point for managing content that might be used in a blog or cms. The full CRUD is implemented on the server and client. ### Files structure The file structure is similar to that of the mean project itself `Fundamental` Files at the `root` of the package **Server** Packages are registered in the **app.js** Defines package name, version and `mean=true` in the **package.json** All of the Server side code resides in the `/server` directory. Server --- config # Configuration files --- controllers # Server side logic goes here --- models # Database Schema Models --- routes # Rest api endpoints for routing --- views # Swig based html rendering **Client** All of the Client side code resides in the `/public` directory. public --- assets # JavaScript/CSS/Images (not aggregated) --- controllers # Angular controllers --- config # Contains routing files --- services # Angular services (also directive and filter folders) --- views # Angular views All JavaScript within `public` is automatically aggregated with the exception of files in `public/assets`, which can be manually added using the `aggregateAsset()` function. Files within the `public` directory of the package can be accessed externally at `/[package-name]/path-to-file-relative-to-public`. For example, to access the `Tokens` Angular controller, `tokens/controllers/tokens.js`. ###Registering a Package In order for a Package to work it needs to be registered. By doing this you make the package system aware that you are ready and that other packages are able to depend on you. The packages are registered from within `app.js`. When registering you are required to declare all your dependencies in order for the package system to make them available to your package. ```javascript // Example of registering the MyPackage MyPackage.register(function(app, auth, database) { // ... }); ``` MEAN has 3 pre registered dependencies: - `app` Makes the express app available . - `auth` Includes some basic authentication functions - `database` Contains the Mongoose database connection > All dependencies specified must be registered in order to use them ###Dependency Injection > An injection is the passing of a dependency (a service) to a dependent > object (a client). The service is made part of the client's state. > Passing the service to the client, rather than allowing a client to > build or find the service, is the fundamental requirement of the > pattern. [Wikipedia](http://en.wikipedia.org/wiki/Dependency_injection) Dependency injection allows you to declare what dependencies you require and rely on the package system to resolve all dependencies for you. Any package registered is automatically made available to anyone who would like to depend on them. Looking again at the registration example we can see that `MyPackage` depends on the `Tokens` package and can make use of its full functionality, including overriding it. ```javascript // Example of registering the tokens package MyPackage.register(function(app, auth, database, Tokens) { // I can make use of the tokens within my module MyPackage.someExampleFunction('some parameter'); // I can override functions MyPackage.someExampleFunction = function(param) { //my custom logic goes here }; }); ``` > Packages when in code are used in a capitalized form ###Angular Modules and Dependencies Every package registration automatically creates a corresponding angular module of the form `mean.[package-name]` The package system injects this information into the mean init functions and allows developers to base their controllers, services, filters, directives etc on either an existing module or on their own one. In addition you are able to declare which angular dependencies you want your angular module to use. Below is an example of adding an angular dependency to our angular module. ```javascript // Example of adding an angular dependency of the ngDragDrop to the MyPackage.angularDependencies(['ngDragDrop']); ``` > See the assets section for an example how to add external libraries to > the client such as the `gDragDrop `javascript library ###Assets and Aggregation All assets such as images, javascript libraries and CSS stylesheets should be within `public/assets` of the package file structure. Javascript and CSS from `assets` can be aggregated to the global aggregation files. By default all javascript is automatically wrapped within an anonymous function unless given the option `{global:true}` to not enclose the javascript within a contained scope ```javascript //Adding jquery to the mean project MyPackage.aggregateAsset('js','jquery.min.js'); //Adding another library - global by default is false MyPackage.aggregateAsset('js','jquery.min.js', {global:true}); //Adding some css to the mean project MyPackage.aggregateAsset('css','default.css'); ``` > Javascript files outside of assets are automatically aggregated and > injected into the mean project. As a result libraries that you do not > want aggregated should be placed within `public/assets/js` The aggregation supports the ability to control the location of where to inject the aggregated code and if you add a weight and a group to your aggregateAsset method you can make sure it's included in the correct region. ```javascript MyPackage.aggregateAsset('js','first.js',{global:true, weight: -4, group: 'header'}); ``` >The line that gets loaded in your head.html calls the header group and injects the js you want to include first- > in packages/system/server/views/includes/head.html > ###Settings Object The settings object is a persistence object that is stored in the packages collection and allows for saving persistent information per package such as configuration options or admin settings for the package. Receives two arguments the first being the settings object the second is a callback function ```javascript MyPackage.settings({'someSetting':'some value'}, function (err, settings) { // You will receive the settings object on success }); // Another save settings example this time with no callback // This writes over the last settings. MyPackage.settings({'anotherSettings':'some value'}); // Get settings. Retrieves latest saved settings MyPackage.settings(function (err, settings) { // You now have the settings object }); ``` > Each time you save settings you overwrite your previous value. > Settings are designed to be used to store basic configuration options > and should not be used as a large data store ###Express Routes All routing to server side controllers is handled by express routes. The package system uses the typical express approach. The package system has a route function that passes along the package object to the main routing file typically `server/routes/myPackage.js` By default the Package Object is passed to the routes along with the other arguments `MyPackage.routes(app, auth, database);` Example from the `server/routes/myPackage.js` ```javascript // The Package is past automatically as first parameter module.exports = function(MyPackage, app, auth, database) { // example route app.get('/myPackage/example/anyone', function (req,res,next) { res.send('Anyone can access this'); }); }; ``` ###Angular Routes The angular routes are defined in `public/routes/myPackage.js`. Just like the latest version of mean, the packages use the `$stateProvider` ```javascript $stateProvider .state('myPackage example page', { url: '/myPackage/example', templateUrl: 'myPackage/views/index.html' }); ``` > The angular views are publically accessible via templateUrl when > prefixed with the package name ###Menu System Packages are able to hook into an existing menu system and add links to various menus integrated within Mean. Each link specifies its `title`, `template`, `menu` and `role` that is allowed to see the link. If the menu specified does not exist, a new menu will be created. The menu object is made accessible within the client by means of a *menu angular service* that queries the menu controller for information about links. Below is an example how to add a link to the main menu from `app.js` ```javascript //We are adding a link to the main menu for all authenticated users MyPackage.menus.add({ title: "myPackage example page", link: "myPackage example page", roles: ["authenticated"], menu: "main" }); ``` > You can look at the angular header controller in the mean project for > more info. You can find it `public/system/controllers/header.js` and > see how the menu service is implemented ###Html View Rendering The packages come built in with a rendering function allowing packages to render static html. The default templating engine is *swig*. The views are found in `server/views` of the package and should end with the `.html` suffix Below is an example rendering some simple html ```javascript app.get('/myPackage/example/render', function (req,res,next) { MyPackage.render('index', {packageName:'myPackage'}, function (err, html) { //Rendering a view from the Package server/views res.send(html); }); }); ``` ###Overriding the default layouts One is able to override the default layout of the application through a custom package. Below is an example overriding the default layout of system and instead using the layourts found locally within the package ```javascript MyPackage.register(function(system, app) { app.set('views', __dirname + '/server/views'); // ... ``` > Please note that the package must depend on `System` to ensure it is > evaluated after `System` and can thus override the views folder ### Overriding views You may override public views used by certain core packages. To create a custom home page, you would create a custom package and modify the script in it's public folder like so: ```javascript angular.module('mean.mycustompackage', ['mean.system']) .config(['$viewPathProvider', function($viewPathProvider) { $viewPathProvider.override('system/views/index.html', 'mycustompackage/views/myhomepage.html'); }]); ``` This will render *mycustompackage/views/myhomepage.html* as the home page. ### Creating your own package To create your own package and scaffold its initial code, run the following command: ```bash $ mean package