People just before a start

Useful setup that I always use when starting a new project

This post was originally published on Go there for slightly nicer code snippets. ✌️

1. Use version control — git

We start with an obvious one. Even if you don’t work on software, use version control, and commit regularly. It will pay off when you make mistakes (everyone does them). When it comes to my projects, I always have to add .idea to .gitignore because I'm using WebStorm 🙄

2. Use .editorconfig

Tabs vs spaces? Inconsistent indent between different files or between team members? There is a well-established solution for that. Even if you are the only person working on the project, do yourself a favor and share.editorconfig between your projects. Most IDEs will read that file and keep the format of files the way you want.

root = true[*]
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
indent_size = 2

3. Add linters

Linters everywhere! Really.

4. Add Prettier

Prettier is an opinionated code formatter. Linters do affect the way your code looks but prettier is much more in terms of styling the code. It offers support for multiple languages. The reason to use it is similar to linters — the code should look like written by a single person. Consistency is worth aiming for because it makes it easier to read the files.

5. Automate it!

Having linters and prettier running in Continues Integration is a must. If the rules are violated then the build should fail. The bigger the project is the longer it takes to analyze the whole codebase. I am a big fan of linting only the files that were changed. So I am using:

  • Lint staged — to run linters only against files that were changed.
"husky": {
"hooks": {
"pre-commit": "lint-staged"
"lint-staged": {
"*.js": [
"prettier --write",
"eslint --cache --fix"
"*.css": "stylelint \"src/**/*.css\" --fix"
Lint staged at work
Lint staged at work
Lint staged at work
git commit -m "Blog Post 005: Powerful start" --no-verify

6. Setup CI to deploy quickly

That’s another thing worth investing time in the beginning. The easier it is to deploy the better. Of course, set the pipeline and deploy only when tests are passing and linters are satisfied. I’m not giving any recipe this time because it differs between projects. If you use a service like Netlify then it should be super easy to do it. If you use something else invest the time to set up the process.

7. Dependabot

Updating your dependencies is important because you get security fixes and regular bugs fix. But who has time to remember about it? No-one. So it’s better to automate that process. If you happen to have tests in place with decent coverage then ideally you should be able to just merge Pull Requests created by Dependabot.


That’s it. A few tools, a few configuration files, maybe two services to keep your project great and ready for fast deployment. I found myself adding these ingredients to every project I work on: server-side (in nodejs), React, Ember, Angular, standalone library, Chrome extension, React Native application, and so on. As you see, it’s not bounded to any technology so it’s hard to come up with a starter pack.

I connect humans and machines. Usually write about interfaces, digital products, and UX on Founder of A bit nerdy 🤓