Edit Page

Generators

A big part of Sails, like any framework, is automating repetitive tasks. Generators are no exception: they're what power the Sails command-line interface any time it generates new files for your Sails projects. In fact, you or someone on your team probably used a generator to create your latest Sails project.

When you type

sails new my-project

sails uses its built-in "new" generator to prompt you for your app template of choice, then spits out the initial folder structure for a Sails app:

my-project
  ├── api/
  │   ├─ controllers/
  │   ├─ helpers/
  │   └─ models/
  ├── assets/
  │   └─ …
  ├── config/
  │   └─ …
  ├── views/
  │   └─ …
  ├── .gitignore
  …
  ├── package.json
  └── README.md

This conventional folder structure is one of the big advantages of using a framework. But it's usually also one of the trade-offs (what if your team or organization has made firm commitments to a different set of conventions?).

Fortunately since Sails v0.11, generators are extensible and easy to check in to a project repository or publish on NPM for re-use.

Sails' generators allow you to completely customize what happens when you run sails new and sails generate from the command-line. By augmenting new apps and newly-generated modules, custom generators can be used to do all sorts of cool things:

  • to standardize conventions and boilerplate logic for all new apps across your organization
  • to swap out rules in the default .eslintrc file
  • to customize how the asset pipeline works in new projects
  • to use a different asset pipeline altogether (like Gulp or webpack)
  • to use a different default view engine
  • to automate custom deployments (e.g. white label apps with one server per customer)
  • to include a different set of dependencies in the package.json file
  • to generate files in a transpiled language like TypeScript or CoffeeScript
  • to start off with all documentation and comments in a language other than English
  • to include ASCII pictures of cats at the top of every code file (or license headers, whatever)
  • to standardize around a particular version of a front-end dependency (for example, sails generate jquery)
  • to include a particular front-end framework in your new Sails apps
  • to make it easy to include new Vue / React components or Angular modules from your favorite templates (for example, sails generate component or sails generate ng-module)

If you are interested in making custom generators, the best place to start is by checking out the introduction to custom generators. You also might check out open-source generators from the community, in case something already out there will save you some time.

Is something missing?

If you notice something we've missed or could be improved on, please follow this link and submit a pull request to the sails repo. Once we merge it, the changes will be reflected on the website the next time it is deployed.

Sails logo
  • Home
  • Get started
  • Support
  • Documentation
  • Documentation

For a better experience on sailsjs.com, update your browser.

Check out the full Sailsconf 2022 playlist on Youtube

Tweet Follow @sailsjs

Documentation

Reference Concepts App structure | Upgrading Contribution guide | Tutorials More

Concepts

  • Actions and controllers
    • Generating actions and controllers
    • Routing to actions
  • Assets
    • Default tasks
    • Disabling Grunt
    • Task automation
  • Blueprints
    • Blueprint actions
    • Blueprint routes
  • Configuration
    • The local.js file
    • Using `.sailsrc` files
  • Deployment
    • FAQ
    • Hosting
    • Scaling
  • E-commerce
  • Extending Sails
    • Adapters
      • Available adapters
      • Custom adapters
    • Custom responses
      • Adding a custom response
    • Generators
      • Available generators
      • Custom generators
    • Hooks
      • Available hooks
      • Events
      • Hook specification
        • .configure
        • .defaults
        • .initialize()
        • .registerActions()
        • .routes
      • Installable hooks
      • Project hooks
      • Using hooks
  • File uploads
    • Uploading to GridFS
    • Uploading to S3
  • Globals
    • Disabling globals
  • Helpers
    • Example helper
  • Internationalization
    • Locales
    • Translating dynamic content
  • Logging
    • Custom log messages
  • Middleware
    • Conventional defaults
  • Models and ORM
    • Associations
      • Many-to-many
      • One way association
      • One-to-many
      • One-to-one
      • Reflexive associations
      • Through associations
    • Attributes
    • Errors
    • Lifecycle callbacks
    • Model settings
    • Models
    • Query language
    • Records
    • Standalone Waterline usage
    • Validations
  • Policies
    • Access Control and Permissions
  • Programmatic usage
    • Tips and tricks
  • Realtime
    • Multi-server environments
    • On the client
    • On the server
  • Routes
    • Custom routes
    • URL slugs
  • Security
    • Clickjacking
    • Content security policy
    • CORS
    • CSRF
    • DDOS
    • P3P
    • Socket hijacking
    • Strict Transport Security
    • XSS
  • Services
  • Sessions
  • Shell scripts
  • Testing
  • Views
    • Layouts
    • Locals
    • Partials
    • View engines

Built with Love

The Sails framework is built by a web & mobile shop in Austin, TX, with the help of our contributors. We created Sails in 2012 to assist us on Node.js projects. Naturally we open-sourced it. We hope it makes your life a little bit easier!

Sails:
  • What is Sails?
  • Community
  • News
  • For business
About:
  • Our company
  • Security
  • Legal
  • Logos/artwork
Help:
  • Get started
  • Documentation
  • Docs
  • Contribute
  • Take a class

© 2012-2022 The Sails Company. 
The Sails framework is free and open-source under the MIT License. 
Illustrations by Edamame.