David Authier
Développeur freelance
As a freelance developer, I work on miscellaneous projects, from the simple single page application to the big API deployed on multiple servers. Some projects share a common environment. For those projects, I ended up creating starters with my teammate Maylis. At the moment we have three starters which come with two environments: development and production.
We mainly use this one to prototype stuff or when we are asked to deliver a static website.
We used this one two times this year for branded mini-games, but I think it can be used for any SPA if you’re okay with using Vue.js :)
We made this one for working on WordPress websites.
For Static site starter and WordPress starter, I chose Gulp to compile static assets (for example: Pug > HTML or Sass > CSS). I find Gulp tasks understandable because you just need to write a JavaScript function which starts by the file you want to transform, then chain whatever transformations you need and finally, specify where the result should be written. Plus the Gulp API is simple and efficient.
Then there is Webpack that I use in all starters to bundle JavaScript files. I replaced my usual Gulp/Browserify a year ago because at some point it was a real mess to handle different types of files inside my JS, manage old libraries that use global scopes, improve compilation duration… Sure Webpack is a bit hard to apprehend, but it does an excellent job at handling your JS. If you don’t know about Webpack, you should definitely have a look at this post.
Since the old days when Maylis and I were doing Ruby projects, we were using Pug-like templating system (like Haml or Slim). My colleague writes tons of HTML, so having a templating solution based on indentation makes the templates more comfortable to read and faster to write. Pug provides some helpful tools for templating: variables, functions, loops, partials. The same goes for Sass. As for Vue.js, I like the way its template syntax works. Writing the template then the JS and let the framework handling the rest is pretty sweet.
Finally, there is Docker, a tool designed to make it easier to create, deploy, and run applications isolated from the host system. I mainly use it to run stuff locally (MySQL, Apache, Nginx) alongside with Docker Compose. That way I can quickly match the production requirements during the development phase. It is an excellent way to drastically reduce the amount of (bad) surprises that could come during production.
As a cherry on the top, I put every command in a Makefile. So whenever Maylis or I start a project, the only command we have to remember is make, which fetches the dependencies and starts the development server. Other than that I always set a make build command to build optimized assets for production. I recommend reading this article if you’re new to Make and want to discover plenty of things that you may implement using it. Make is a build automation tool appeared in 1976. So we can say that it is quite reliable ;)
This is not present in WordPress starter but we used Wordmove in our last WordPress project. It’s a tool to deploy WordPress sites which supports multiple environments and granular deployments (meaning that you can only deploy uploads if you want to). Wordmove works in both way: you can push from local to production, and you can pull from production to local. That is interesting because when you work on a WordPress, there is a strong dependency between your database and your work. A few examples: Some template has to be used for specific pages, or some configuration has to be changed through the admin panel. So doing it once and being able to duplicate it everywhere (with a few variations depending on the environment) is a useful feature. Also by doing so, there is no difference between local DB and production one. That is a good way to avoid mistakes and simplify the debug process.
Almost every project comes with some changes on the starter. So I usually take notes all along the project, and at the end, I look at each feature I listed and ask myself: “Is that specific to the current project or should it be added in the starter?”. That way I always keep my starters up-to-date. As for the dependencies, I always take some time before starting a new project to update them in the starter before using it.
Hope our starters will be useful to other developers :)
David Authier
Développeur freelance