When you start a new project the temptation is to jump right into the “fun” part: writing code. Setting up linting, formatting and testing feels like “admin work” you can do later.

This is a trap

Fast forward two weeks, your code works but it’s a mess. Formatting is inconsistent, you are terrified to refactor anything in case it breaks and adding a new feature feels like you are playing Jenga. You are living in chaos.

The best time to set up your proffessional development environment is in the very beginning. A few minutes of setup now, saves you hours of pain later.

This post will help you build the essential scaffolding for any pro project.

• Linting (Finding code problems)
• Formatting (Making it look consistent)
• Testing (Making it robust)
• CI/CD (Automating it all)

Part 1: EsLint + Prettier

First, let’s stop arguing about tabs vs. spaces. Your team (even if it’s just you) needs a single source of truth for code style. This is the first step out of chaos.

ESLint is a linter. It analyzes your code and finds problems. Think: “You declared this variable but never used it,” or “You’re using var when you should be using let or const.” It catches potential bugs and enforces best practices.

Prettier is an opinionated formatter. It doesn’t care about your logic; it only cares about style. It takes your messy code and auto-formats it based on a set of rules (e.g., max line length, single vs. double quotes).

Why use both? ESLint catches bugs. Prettier enforces style.

The Setup

Let’s install them as dev dependencies:

npm install --save-dev eslint prettier eslint-config-prettier

• eslint-config-prettier is the secret sauce. It turns off all ESLint style rules that might conflict with Prettier, letting Prettier do its one job perfectly.

Create a .prettierrc.json file in your project root. This is where you put your (very few) style choices:

// .prettierrc.json
{
"semi": true,
"trailingComma": "es5",
"singleQuote": true,
"printWidth": 80
}

Create a .eslintrc.js file. This one is more complex, as it handles logic:

// .eslintrc.js
module.exports = {
extends: [
'eslint:recommended', // Start with sensible defaults
'prettier', // This MUST be the last one
],
root: true,
env: {
browser: true,
es2021: true,
node: true,
},
// ...add framework-specific rules here
// (e.g., 'plugin:react/recommended')
};

Finally, add these scripts to your package.json:

"scripts": {
"lint": "eslint . --ext .js,.jsx,.ts,.tsx",
"format": "prettier --write ."
}

Part 2: The Safety Net (Jest)

Linting stops you from writing messy code. Testing stops you from writing broken code.

If you skip this step, you will eventually break something, and you won’t know it until it’s too late. Setting up testing early builds a safety net that catches you before you push a bug.

Jest is a fantastic “all-in-one” testing framework that’s popular, well-documented, and easy to set up.

The Setup

npm install --save-dev jest

Add to package.json:

"scripts": {
"test": "jest",
// ...your other scripts
}

Let’s say you have a simple function in utils/sum.js:

// utils/sum.js
function sum(a, b) {
return a + b;
}

module.exports = sum;

Create a test file utils/sum.test.js (Jest automatically finds .test.js files):

// utils/sum.test.js
const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});

Now run npm test. You just wrote your first unit test! This simple test ensures that if someone ever breaks the sum function, you’ll know immediately—not when a user complains.

🤖 Part 3: CI/CD with GitHub Actions

So, you have linters and tests. But... what if you forget to run npm test before you push? All that setup is useless if you don’t use it.

This is where your CI/CD comes in.

Continuous Integration (CI) is the practice of automating these checks every time you push code. It “integrates” your work by verifying it against the main codebase.

Continuous Deployment (CD) is automating the release of that code (e.g., to production) if it passes all the checks.

We’ll focus on CI. GitHub Actions is the easiest way to start, as it’s built right into GitHub.

The Setup

In your project root, create a new folder: .github

Inside that, create another folder: workflows

Inside that, create a file: ci.yml

Paste this into ci.yml:

name: Node.js CI

# Run this workflow on every push and pull request
on: [push, pull_request]

jobs:
build:
# Use the latest stable version of Ubuntu
runs-on: ubuntu-latest

steps:
# 1. Check out your repository code
- name: Check out repository code
uses: actions/checkout@v4

# 2. Set up the Node.js version you use
- name: Use Node.js 18.x
uses: actions/setup-node@v4
with:
node-version: '18.x'

# 3. Install your project's dependencies
- name: Install dependencies
run: npm install

# 4. Run the linter
- name: Run linter
run: npm run lint

# 5. Run the tests
- name: Run tests
run: npm test

Commit and push this file.

That’s it.

Now, every time you push code, a virtual machine will spin up, check out your code, install dependencies, and run both your linter and your tests. If npm run lint or npm test fails, you’ll see a big red ❌ next to your commit.

This is your ultimate safety net. It makes all the previous setup enforceable and automatic. It’s the final piece of the “no chaos” puzzle.

🏁 It’s a Mindset, Not Just Tools Setting up a professional environment isn’t about using the flashiest new tool. It’s about building a mindset of automation, consistency, and confidence.

By setting this up early, you avoid technical debt, stop bugs before they start, and create a system that lets you code with confidence.

With this setup (ESLint + Prettier + Jest + GitHub Actions), you’ve built a system that:

Keeps your code clean (Prettier)

Catches bugs early (ESLint)

Prevents regressions (Jest)

Automates your quality checks (GitHub Actions)

You can now refactor, add features, and collaborate, knowing your trusty butler is watching your back.

What’s one tool in your professional setup you can’t live without? Drop it in the comments!