DEV Community: Ramon Silva

Stop Pushing Broken Code: Clean Git Hooks Without External Packages

Ramon Silva — Wed, 07 Oct 2026 00:18:15 +0000

How many times have you pushed a commit only to realize 3 minutes later that you left a console.log, a formatting issue, or a broken unit test in your pull request?

Most JavaScript and TypeScript teams immediately reach for external tools like Husky or lint-staged. While those tools are great, many developers don't realize that Git has had native client-side hooks built-in since day one—and you don't need any npm dependency to protect your repository.

Here is how you can set up a native, version-controlled pre-commit hook in under two minutes.

The Problem With the Default `.git/hooks` Folder

By default, Git stores hooks inside the .git/hooks/ directory of your project.

The problem? The .git/ folder is never committed to remote repositories. That means your teammates won't get your hooks, and you won't get theirs.

Luckily, Git 2.9 introduced a clean configuration setting: core.hooksPath.

Step 1: Tell Git Where to Look for Hooks

Instead of relying on hidden folders, create a tracked directory in your project root called .githooks:

mkdir .githooks

Now, tell Git to read hooks from this directory:

git config core.hooksPath .githooks

(Tip: In a team project, you can add this line to your npm prepare script in package.json so it runs automatically on npm install!)

Step 2: Create Your Native `pre-commit` Hook

Inside your new .githooks/ folder, create a file named pre-commit (no extension):

touch .githooks/pre-commit
chmod +x .githooks/pre-commit

Add your validation logic inside .githooks/pre-commit:

#!/bin/sh

echo "Running pre-commit checks..."

# 1. Run your linter or type-checker
npm run lint
if [ $? -ne 0 ]; then
  echo "Lint errors found! Fix them before committing."
  exit 1
fi

# 2. Block unwanted console.log leftovers
if git diff --cached | grep -q "console.log"; then
  echo "Warning: Found staged console.log statements!"
  exit 1
fi

echo "All checks passed! Committing changes..."
exit 0

Step 3: Try It Out

Whenever you run git commit, Git executes your .githooks/pre-commit script before creating the commit snapshot:

If the script exits with 0, the commit goes through.
If any test or lint fails (exiting with non-zero), Git instantly aborts the commit, keeping your Git log clean.

Why Keep It Native?

Zero dependencies: No extra node_modules bloat or build-step overhead.
Instant execution: Runs directly in your shell without wrapper lag.
Works with any stack: The same hook works whether your project is React, Node.js, Go, or Python.

Small native features like core.hooksPath save hours of CI debugging and keep your codebase clean.

Have you used native Git hooks before, or do you prefer package managers like Husky? Let's discuss in the comments!

Stop Creating Useless Instances in TypeScript

Ramon Silva — Tue, 10 Mar 2026 20:50:08 +0000

Confess to me: how many times have you seen (or written) code where someone creates a class full of utility functions and, when it's time to use it, does a new CurrencyFormatter() just to call a method that formats a number?

Yeah. We often do this on autopilot, but in practice, we are allocating memory for a whole object without any real need.

If your function doesn't need to hold any internal "state" (meaning it doesn't use data from a specific instance), you don't need the new keyword. That's exactly what the static keyword is for.

Let's see the difference in practice.

❌ The useless `new` nightmare (Without static)

Imagine a simple utility class for formatting. If you don't use static, TypeScript forces you to instantiate the class (create an object) every single time you want to use its function:

class CurrencyFormatter {
  format(value: number) {
    return `$${value.toFixed(2)}`;
  }
}

// Wasting memory to create an object for no reason
const formatter = new CurrencyFormatter(); 
const result = formatter.format(150.5);

✅ Straight to the point (With static)

class CurrencyFormatter {
  // The function now belongs to the class
  static format(value: number) {
    return `$${value.toFixed(2)}`;
  }
}

// No 'new', no mess. Direct call!
const result = CurrencyFormatter.format(150.5);

🧠 Bonus: Sharing data across instances

The static keyword isn't just for utility functions. It's incredibly powerful for creating variables that need to be shared across all objects of that class.

Imagine you are processing transactions in a financial app and want to keep track of the total number of transactions created during a session. If you use a regular variable, each transaction will have its own isolated counter (which defeats the purpose). With static, the whole class shares the same variable:


class Transaction {
  // This value is shared across the entire application
  static totalProcessed = 0; 

  constructor(public amount: number) {
    // Every time a transaction is created, we update the global counter
    Transaction.totalProcessed++; 
  }
}

new Transaction(100);
new Transaction(50);
new Transaction(25);

console.log(Transaction.totalProcessed); // Output: 3

The Golden Rule

Not sure if you should use it or not? Ask yourself this: "Does this method use the this keyword to access a variable that belongs only to this specific object?" If the answer is no, slap a static on it and be happy! Your code will be cleaner, more performant, and more professional.

Do you use static methods often in your projects, or do you still have the habit of throwing new at everything? Let me know in the comments!

Hype Doesn't Dictate the Market: The Real Deal on Development

Ramon Silva — Wed, 26 Feb 2025 01:06:14 +0000

Hey guys!

I recently went to a dev meetup here in my city. While chatting about the job market, one comment really caught my attention: "Java is making a huge comeback after a slump." That made me stop and wonder: when did it ever leave?

Honestly, I don't think Java ever left the stage. Even as a front-end dev, I see the demand for Java developers booming, especially in the enterprise world. Companies need people to build new features and maintain legacy systems. And let's face it, their real concern isn't chasing trends, but keeping everything running smoothly. Mission-critical systems aren't replaced overnight. Stability, security, and longevity matter way more.

One thing we can't ignore is the role social media plays in this perception, constantly feeding us what we already search for and related topics. That's where the danger of "bubbles" lies. Algorithms are designed to show us content that reinforces our beliefs and interests, creating a vicious cycle of information that can lead us to believe a specific tech stack is the only relevant one, when in reality, the market is much more diverse.

So, before you get swept up in the "X is dead" or "Y is going to dominate everything" narratives, remember that the market is way more complex than the current hype. At the end of the day, every language has its purpose. Knowing this is what helps you decide where to invest your time and energy as a dev. Seek information from diverse sources, talk to professionals from different fields, and experiment with new technologies. The real key to success is the ability to adapt and learn continuously.