Service Scaffolding

Background
We’ve had great success in the past using the service-template-node project to facilitate creation of NodeJS-based services that follow established best practices and conventions, but improvements are possible.

One pain point is that the template repository serves as both a starting point for new projects, as well as a source of common code. This necessitates that as bugs are found and fixed, or improvements are made, changes from the template be merged into service repositories. This requires service maintainers to monitor for changes, and deal with the fallout of inevitable merge conflicts. To solve for this, common (reusable) code should be placed in shared libraries and imported into projects. Identifying and incorporating updates of these shared libraries can then be carried out in the usual, idiomatic way.

With all reusable code in libraries, what remains is boilerplate to facilitate getting started, and document expected layout and conventions. There is no expectation that changes here will ever need to be merged forward. This approach is being referred to as scaffolding to differentiate it from the previous approach. Why scaffolding? From Wikipedia:"Complicated software projects often share certain conventions on project structure and requirements. For example, they often have separate folders for source code, binaries and code tests, as well as files containing license agreements, release notes and contact information. To simplify the creation of projects following those conventions, 'scaffolding' tools can automatically generate them at the beginning of each project. Such tools include Yeoman, Cargo and Ritchie CLI."Though we’re not initializing a new tree by generating the files, the approach outlined here is conceptually identical.