My team is reviewing how we start-up our projects, a large time sink for us is the initial set-up for running a prototype or Proof of Concept. We end up repeating similar repo and language/framework boilerplate over and over.
This boilerplating that we do for our projects is ripe for automation; we're looking at GitHub's templates for doing some of the heavy lifting around repo creation and we're looking for ways to automate adding GitHub Actions.
When it comes to generating project-specific boilerplate we're looking at language-specific tools but this in early stages.
This has led us to wonder what everyone else does, so, how do you automate your boilerplate for projects?
Is it templates, scripts or interns?
No interns were forced to do repetitive tasks in the making of this post, cover photo from pexels.
Top comments (38)
Why not just create a boilerplate repo that you can clone for each new project? Or if you want to get a little more fancy you could write a cli that scaffolds things for you with generators to create new files with template/boilerplate code prepopulated. You basically would be making your own framework.
What language do you primarily use? Maybe I can suggest some tools if you let us know
Template repos is what we’re currently thinking! Some scripts to generate some basic CI and implement a few hooks etc,
Something like building out a framework would be really interesting but we’re looking first at 0 - 1 then we can talk about those sort of things!
Primarily Python, with some Node and C# sprinkled in depending on the project! Any ideas?
I think a boilerplate repo would be the quickest and easiest to create and setup. I personally do this all the time for my own projects. I also like to search github for other boilerplates or starter kits and steal other peoples ideas.
You can search for things like flask boilerplate or whatever tool/language you use.
You can also use tools like hygen for code generation: hygen.io/
You also might be able to abstract certain parts into their own packages/modules and then just pull them in as dependencies.
Stuff like this takes a lot of iteration and experimentation. Overtime you will find what works best for you and your team. Start simple at first with just a repo you can clone and also see what other people are doing on Github.
Think you’re right, maybe a generic one to start - then we can fork it for each specific ones we need if we start to use them repeatedly, I think bare bones will be the start just to get it in use,
Hygen looks interesting will have to give it a try!
And yeah, seems like it’ll definitely change as we start to use it but sourcing everyone’s wisdom here will hopefully mean we can start making some big changes fast when people get used to it!
Boilerplate repos, without sprinkling GH action fairy dust over them, have one big problem – all the TODO and FIXME places where customization has to be done – they simply get ignored 80% of the time.
Hmmm, maybe we could automate that "replace things by variables in texts" thing? 😏
Honestly, since the post we've been using cookie-cutter, mostly, to great success but have tried playing around with templates and GH Actions will need to revisit it properly but that manual process initially put me off!
We use templates for projects that we often use:
cookiecutterfor python, and
Cookiecutter looks like it'll be a solid shout for some of our python scaffolding, it's something we always fall back to using!
Thanks for sharing your templates though, definitely going to take a look at them
We've abstracted an in-house framework using common elements and base classes and made them available through a dependency package.
We simply initialize the core framework product, add our package as a dependcy, and then wire up the chunks of functionality we actually need. All of this is done through basic service configuration using dependency injection, and takes maybe 20 minutes.
Very cool - we'd glanced at GitHub's packing tools but not given it a proper consideration - how long did it take you to get to that as your solution?
PHP support traits, which means we can quickly attach chunks of functionality to our base classes.
For example, our database entities all have a date_created and date_updated fields. Instead of having to touch these for every entity, we can simply add our "Dated" trait from our base package and now all the getters/setters and date management functionality is included out of the box.
We also do this for bigger things like user management, firing webhooks, sending emails, etc.
Whenever we have shared common functionality between our services we add it to the base package and it becomes instantly available to all developers in the company.
Interesting - so when you abstract out this common functionality do you find there can be much bloat in the packages that you’re creating? Lots of unused methods etc?
I’m thinking of how we could implement something like this, wrapping it up like some helper libraries we’ve created in the past but we’ve always ended up ballooning the scope of each lib
This is for our backend projects, so package size typically isn't so much an issue.
Additionally, our use of dependency injection patterns makes our services fairly efficient.
From a use perspective, we typically only include functionality that is shared amongst all of our other Microservices. We've purposely designed our applications to promote interoperability.
Sounds really sustainable, this seems like it'll be a longer-term goal for us but could have some big payoffs,
Thanks for sharing!
It's more powerful than GH templates and pretty easy to setup and maintain.
Hmm okay, more and more advocates for Hygen.io!
What do you think makes it easier to maintain?
You can update your templates and then test right there in the CLI. With GH templates you need to go through the process of creating a new repo.
Also hygen.io supports scripts. E.g. you can run npm install after generating your project.
GH templates don't even support variable substitution.
Ohh the scripting and substitution do sound like they'd win out on top of GH templates,
Variations depending on individual templates seem the most time consuming forking the template to make a template etc, guess that gets around all of that!
We built a Framework that underlies all the different Rails applications that my team maintains and owns. We also modularized our own scripting language and DB versioning system:
We’ve not used much rails (dam) but I’m sure there’ll be lessons take a look, custom scripting and versioning sounds like it’ll be interesting!
I create my own templates/boilerplate and then use github.com/Rich-Harris/degit. However you can run degit on any github repo so essentially you have access to a ton of templates. I have no idea about automatically adding GitHub actions but I'm also curious.
Ohh interesting, never heard of this but being able to lift templates from what we've done in the past could lead to some pretty quick velocity on getting us started!
In the brief look, I've had, if registered, it should be just adding them to the repo but I think you might be able to add them to a GH template,
Awesome thanks for letting me know!
I use a boilerplate for my npm packages that include the tools I am used to work with: Babel 7, mocha, chai, standard, jsdoc
While this is very opinionated it perfectly fits my routine, so I can hands on immediately
How do you implement the boilerplate for these? Just a standard repo you clone and change?
And mocha and chai and fantastic
Sorry, I forgot to add this information. It's a template repository: github.com/jankapunkt/npm-package-...
You can create new repositories, based on templates: help.github.com/en/github/creating...
Ohhh nice I'll take a look at your template!
For anyone interested, here's two posts describing the process that we follow in my company
Automating boilerplate code generation with Node.js and Handlebars
John Kapantzakis ・ Feb 18 ・ 3 min read
Including files created by Node.js into .Net project 🛠
John Kapantzakis ・ Feb 21 ・ 6 min read
Ohhh nice! Thanks I’ll give these a read!
I have a repo with boilerplate in Github that I use for CLI tools. We've used a similar technique for miceoservices at work too.
Both use a simple shell script to rename file and packages etc.
Take a look at github.com/dnnrly/goclitem
Ahh thanks for the link will take a look and see what we can gleam from it!
From my experience, most templates that I use or create are doomed to be outdated someday, as we as a community uncover ways to improve how we build software. Having a template also means having to keep it in sync with how the template is actually used, or it is doomed to become out-of-sync. It created a lot of overhead and friction for me.
Nowadays in my projects, I try to write code that is easy to delete, so that when I create a new project, I can take the latest project, or one of the older projects, delete all the project-specific code, and develop based off that.
From time to time I noticed patterns many of my projects. That is when I create reusable stuffs such as tkt, xprs, vuetoy, or tailwindtinth. Now I usually avoid creating reusable stuff, until I am very sure that it is indeed reusable.
Being QA the boilerplate is around test structure for xunit. I looked into some Visual Studio templates, but I do not like the management or distribution process for them.
Our devs would say that they fork a repo. Original it was a dotnet template. I disagree that it is a template and have been pushing that it is a product implementation and that conceptually we are in fact forking for each new client. Client work should contribute and take this baseline. Several developers are now pushing for the same thing.
I actually have two boilerplate repos: 1) is an app template (but now not always needed because of nuxt-create-app, which I think does a great job at starting me up, but I go faster when I don't have to npm install stuff all over again), and 2) a "component design studio". The latter is my favorite where I can focus more on tiny and specific components that can be re-used in multiple projects. I guess someday I'll give bit a try.
cookie cutter all the way.
I don’t know how I’ve not spotted this before, definitely worth a shot! Thanks!
Project scaffolding is the good kind of programmer laziness, thus Springerle, my collection of cookiecutters (Python).
I've been working on a web-based tool that lets you quickly create a Node/React codebase with everything they need: divjoy.com. Would love to hear your thoughts!