Yeoman Fountain generators

Fountain Documentation

Contributing to FountainJS

You can find here guidelines about how to contribute to FountainJS. This concerns every submodules of the project.


The simplest way for you to contribute is by creating issues for reporting a bug or asking for a feature.

Issue location

  • Every issue or feature request should be in the related repository (if your issue concerns Gulp, post it in generator-fountain-gulp).
  • If the issue is a general question or a general feature request, you should post it in generator-fountain-webapp.
  • As a contributor, you might want to post issue about the coding environment. If so, you can post it in the meta-repo fountain.

Issue template

For a fastest support we will recommend you to follow and complete the issue template provide on Github.


FountainJS generator is divided into multiple sub-generator.

  • As a user, the main entry point is generator-fountain-webapp.
  • As a developer, the main entry point is fountain.It is a meta-repo containing submodules. Each of them is a generator for a specific feature (gulp, angular1...). You can find the full list here. Every commit of fountain repo is linked to a specific commit of every submodule.

If you want to know more about submodules,


In order to install the full environment on your local machine. You have to do the following:

$ git clone [email protected]:FountainJS/fountain.git
$ cd fountain
$ npm install
$ git submodule update --init --recursive

The last command will clone every submodule.
Then you need to link every submodule between each other.

$ npm run linkAll

This will also run npm install inside each submodule repo.


We provide end-to-end tests. You can find them in fountain/test/test.js.
This contains a series of test executed on every combinations of generated project. You can also choose the stack you want to run the tests on by using fountain/test/interactive.js.

$ mocha test/test


$ mocha test/interactive

The following tests are executed on the generated project:

  • lint the project (both source code and configuration code) regarding its linting rules
  • run project unit tests
  • run gulp serve and
    • test if the list of techs is displayed
    • test live reload for JS files
    • test live reload for css/scss/less/styl files
  • run gulp serve:dist and test if the list of techs is displayed

Tests are ran by Mocha and we use Saucelabs and WebdriverIO for remote browser tests.

Coding rules


In every submodule of FountainJS you can use ES2015 syntax. You can find more about it here
However, the code has to be compatible with Node 4 minimum. If you are using Node 5, we strongly encourage you using nvm and test your code on Node 4 as well. You can find which ES2015 features you can use or not here

Linting rules

We use ESLint as style linter with a shared configuration using XO rules. Please follow this syntax otherwise build tests won't pass. XO configuration is set in package.json as an extension of eslint. The generated projects may use additional plugins such as eslint-config-xo-react. We use the space version of XO which uses 2-space indent.

Coding style

You are encouraged to follow the coding style of the whole project to keep consistency.

Pull Requests

If you want to propose a fix or a feature, do as follow:

  • Fork the generator
  • Open a pull request describing the fix/feature
  • Reference the issue when appropriate
  • Make sure your branch can be automatically merged, otherwise rebase your branch
  • Make sure Travis tests are green

Pull Request template

In any case, every pull request must follow this template:

  • Please check if the PR fulfills these requirements
    [ ] Travis tests for the changes are green for the meta-repo
    [ ] Travis tests for the changes are green for the repository you contribute to

  • What kind of change does this PR introduce ? (Bug fix, feature, docs update, ...)

  • What is the current behavior ? (You can also link to an open issue here)
  • What is the new behavior (if this is a feature change) ?
  • Does this PR introduce a breaking change ? (What changes might users need to make in their application due to this PR?)
  • Other information:

Build tests

We use Travis for running tests before merging pull requests. Locally, you can run the same tests using mocha test/test. Pull requests will not be merged if the build is not green.