This repository has been archived by the owner on Feb 28, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 21
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 otherEventEmitter
- Functions that sometimes execute asynchronously, should always execute asynchronously
- Functions that return a
Promise
should not throw synchronous exceptions--limit the code outside thePromise
- 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
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:
- If the user aborts the process during prompting, no files are written to the destination directory
- 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 - 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) - The file writing logic is more easily unit tested
Using the Yeoman memory filesystem also has some benefits (there are some drawbacks as well):
- It has a conflict resolution system for when existing files are altered
- It will write a log message for each file written to disk with the status (create, overwrite, conflict, identical, force) and filename
- The filesystem api has some convenience functions for writing and modifying JSON files
- Writes to the memory filesystem are synchronous