Building a website from scratch can be done in many ways, some of which are long and repetitious, others that make use of templates and clever shortcuts. Forum One uses generator-web-starter to stand new websites up in a sleek and reliable way. However, as technology gives us new and better ways to do things, it’s not without its challenges. Here are some pain points we’ve addressed over time. I recently wrote about the background and benefits of generator-web-starter. It’s an excellent way to stand new websites up quickly and effectively, while ensuring that there are no copy/pasting errors from previous builds and a secure foundation is set. But as a work in progress, we’ve certainly encountered our challenges. To account for bumps in the road, when generator-web-starter 2.0 was released, we also released its companion CLI, forumone-cli, which addresses a few pain points we encountered with previous generator-web-starter versions and with Docker local development.

Accounting for updates

The very first thing the f1 command was able to do was create new projects. We found that developers, not realizing that a new release had been pushed, were in some cases unknowingly scaffolding projects using an outdated version of the generator. As the generator is an extremely crucial part of a new project, we invested time to address it. Our solution asked developers to uninstall their generator and use the new f1 entry point instead. Behind the scenes, this command uses the npx utility to download the most up-to-date version of generator-web-starter to start a project, so that developers no longer need to remember to perform updates. The f1 command itself has a self-update notification plugin built in, so developers are less likely to miss notifications due to the frequency with which they interact with the tool.

Interacting with other tools

The forumone-cli’s other main function is to wrap interactions with the Docker Compose project. By convention, a Docker Compose project is governed by a file called docker-compose.yml. We extend this convention by introducing a sibling file called docker-compose.cli.yml, which houses command-line services that are not run like a server. We used this separate file in order to remove distractions when monitoring a project’s cluster. When asked to strictly monitor containers, Docker Compose does not distinguish between a successful command exit and a server crash. This CLI file contains wrappers for interacting with tools like Composer, Drush, and WP-CLI. These wrappers are the bridge between the developer’s computer and the container environment. For example, Drush needs access to the local database in order to perform tasks like clearing the cache, but it also needs the user’s SSH credentials in order to access a remote server to download database dumps. The f1 drush wrapper forwards the user’s credentials when running a Drush container. As another example, the Composer wrapper shares its cache with all other projects, allowing the user to avoid having to re-download packages that have already been installed before. In addition, the CLI file is used to add shortcuts for project-specific tasks. This CLI file is how users interact with Gesso, if the project has been configured to include it. generator-web-starter defines a service that can be used to interact with the Gulp build tool, and forumone-cli knows to ask Docker Compose to utilize the additional CLI file when users run commands against the container cluster. Users can extend this with whatever wrappers they want. As an example, we often use containers that embed the AWS CLI to interact with locally-compatible services (such as MinIO, which is compatible with AWS S3).

Debugging performance degradation

Finally, forumone-cli offers additional conveniences. It is hard to dismiss the usefulness of a debugger like XDebug, but we have found that keeping it enabled in a container introduces severe performance degradation. As a result, the f1 up command includes a flag to turn XDebug on only when the user requests it. The CLI also integrates with a tool called mkcert in order to transparently install trusted TLS certificates for localhost. Integrating these certificates allows us to encrypt connections to our local machines the same way our sites are encrypted in production, without encountering browser warning dialogs about invalid or untrusted certificates. The f1 up command includes code to provide these certificates to running containers in a predictable location, enabling easy usage of HTTPS for any project.