Skip to content
This repository has been archived by the owner on Feb 28, 2020. It is now read-only.

Developer guidelines

Mike Tunnicliffe edited this page Jul 6, 2017 · 4 revisions

General guidelines for developing generator-swiftserver:

  • Use the app sub-generator for prompting the user
  • Use the refresh sub-generator for writing files to the destination project
  • Use the Yeoman memory filesystem (this.fs, this.copy() and friends) to write files
  • Prefer Promises to callbacks (use the bluebird library for Promises)
  • Avoid new Promise(...) unless you are wrapping a stream or other EventEmitter
  • Functions that sometimes execute asynchronously, should always execute asynchronously
  • Functions that return a Promise should not throw synchronous exceptions--limit the code outside the Promise
  • Prefer running some tests (eg npm test, npm run testintfast) before pushing your code to github
  • Follow the standard code style (https://standardjs.com/), this will be checked by test scripts
  • When writing commit messages, the following guidelines are desirable: https://chris.beams.io/posts/git-commit/
  • When merging pull requests follow the Feature Process and ensure the squash commit message correctly identifies the type of change for standard-version as per Commit format documentation

Detail

The generator separates the concerns of prompting and writing the project between two generators (app and refresh). The app generator is responsible for changing user input into a specification object for the refresh generator. This decoupling has a number of benefits:

  1. If the user aborts the process during prompting, no files are written to the destination directory
  2. You can bypass the prompting logic and drive the back-end logic separately, for example using the --specfile option to create a known test project
  3. Other front-ends can directly drive the back-end logic (although, in practice the app generator can be used as a pass-through with the --spec option)
  4. The file writing logic is more easily unit tested

Using the Yeoman memory filesystem also has some benefits (there are some drawbacks as well):

  1. It has a conflict resolution system for when existing files are altered
  2. It will write a log message for each file written to disk with the status (create, overwrite, conflict, identical, force) and filename
  3. The filesystem api has some convenience functions for writing and modifying JSON files
  4. Writes to the memory filesystem are synchronous