Enforce Code Quality with Husky & Biome in Node.js/TypeScript

We use Git every day across the tech industry, but very few engineers actually understand how it works under the hood. So I built my own version of Git from scratch in TypeScript and Node.js: git-ts Instead of wrapping existing libraries, I implemented Git’s core mechanics directly: - Writing and reading objects using the same binary format as native Git - Hashing file contents with SHA-1 and compressing them with zlib - Parsing and updating the staging area (index file) - Managing branches by manipulating raw references - Traversing commit history using graph algorithms (BFS) to support operations like log and fast-forward merge The result: You can create a commit with git-ts, and the native Git CLI will recognize it seamlessly. That constraint (full compatibility with Git’s internal data structures) was the most challenging and rewarding part of the project. This pushed me far outside typical web development: - Working with binary buffers instead of JSON - Understanding Git as a content-addressable filesystem - Implementing low-level file system operations and graph traversal logic One realization that stuck with me: A Git branch is just a text file pointing to a 40-character hash. If you want to take a look (or roast it), here’s the repo: https://lnkd.in/dH9-UEUF #git #typescript #nodejs #software #VersionControl #DevTools

Waitt… if you're still using git clone like this: git clone <repo-url> Then you're probably downloading way more than you actually need 👀 Better approach?? Here u go ;) ✨ git clone --depth 1 <repo-url> honestly… it's one of those small things that just makes sense once you know it. When you normally clone a repo, Git pulls everything literally the entire history, every commit, every change since day one. But with --depth 1 {aka a shallow clone}, you only get the latest version of the code. No history. No extra baggage. Just what you need. Which means way faster cloning, Saves disk space 🧠 and hell cleaner when you just want to use the project If you've never tried this before, go ahead and give it a shot ;) Follow Sakshi Jaiswal ✨ for more quality content like this. #Frontend #React #Sakshi_Jaiswal #FullstackDevelopment #javascript #TechTips #Git #Clone #flags #Webdev

Stop Googling the same Git commands every single day. Most developers waste 20 minutes daily on commands they've looked up a hundred times before. Here's your quick reference: 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 → git config --global user.name "Your Name" → git config --global alias.st status → git config --list 𝗦𝘁𝗮𝗴𝗶𝗻𝗴 & 𝗖𝗼𝗺𝗺𝗶𝘁𝘁𝗶𝗻𝗴 → git add . → git commit -m "your message" → git diff --staged 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 & 𝗦𝘁𝗮𝘀𝗵𝗶𝗻𝗴 → git checkout -b feature-branch → git branch -d old-branch → git stash save "work in progress" → git stash pop 𝗠𝗲𝗿𝗴𝗶𝗻𝗴 & 𝗥𝗲𝗯𝗮𝘀𝗶𝗻𝗴 → git merge feature-branch → git rebase main → git rebase -i HEAD~3 𝗨𝗻𝗱𝗼𝗶𝗻𝗴 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀 → git revert → git reset --soft HEAD~1 𝗥𝗲𝗺𝗼𝘁𝗲 & 𝗣𝘂𝘀𝗵/𝗣𝘂𝗹𝗹 → git remote -v → git fetch origin → git pull origin main → git push origin feature-branch -f This is just a snapshot. The full cheat sheet has 50+ commands with explanations. Comment "GIT" below and I'll send it to you directly. Save this post - you'll come back to it. Follow Narendra K. for more such content. #Git #BackendDevelopment #Java #InterviewPrep #DevTools

I used to run npm install everywhere without thinking twice… until I started working on real projects 👀 That’s when I discovered npm ci — and honestly, it changed how I handle builds. Here’s the simple difference 👇 👉 npm install (npm i) Good for development. It installs dependencies and can even update your lock file. Super flexible, but not always predictable. 👉 npm ci This one is strict. It installs exactly what’s in your package-lock.json, deletes node_modules first, and gives you a clean, consistent setup every time. And if you’re building for production: npm ci --omit=dev No dev dependencies, faster install, smaller builds 🔥 💡 What I follow now: While coding → npm i While deploying / Docker / CI → npm ci Small change, but it saves you from those “it works on my machine” headaches 😅 #NodeJS #DevOps #Docker #JavaScript #WebDevelopment

This post hit close to home. I’ve seen this a lot in real teams— people try to learn Git by memorizing commands, but that’s usually not where things break. What actually causes issues is simpler: not knowing your current state. Which branch are you on? What changed? What’s staged, and what isn’t? If those aren’t clear, things go sideways pretty quickly. That’s why I always come back to this: check git status look at git diff It’s basic, but it’s the difference between working with Git and fighting it. And honestly, this isn’t just about Git. The people who move fast (and don’t create chaos) are the ones who understand what’s going on right now. Tools come later. Awareness comes first.

Most production bugs I’ve seen around environment variables aren’t caused by missing values. They’re caused by misunderstanding what environment variables actually are. A few things that have burned teams I know: - Environment variables are an OS primitive. Every process gets a flat key-value copy of its parent’s environment. A copy, not a reference. What your child process changes, your parent never sees. - Your .env file does nothing on its own. Something has to read it. And most tools, including dotenv, will NOT overwrite a variable that already exists. So if your shell profile already exports DATABASE_URL, your .env is silently ignored. This is probably the most common “works on my machine” culprit. - Docker starts with a clean slate. It does not inherit your shell environment. If you’re not explicitly passing variables with -e or –env-file, the container doesn’t know they exist. - React’s process.env is not real runtime config. The bundler replaces every reference with a literal string at build time. That value is now hardcoded in the JavaScript your users download. If you put a secret in REACT_APP_anything or NEXT_PUBLIC_anything, it is not a secret anymore. - Build time and runtime are fundamentally different. A frontend bundle bakes values in at build time. An Express server reads the actual process environment when it starts. You can change a backend variable and restart. You cannot do that with a bundled frontend without rebuilding. Deleted a committed secret in the next commit? The key is still in git history. git show will find it. The only fix is to rotate the credential. The mental model that fixes most of this: secrets always runtime, never build time, never committed to source code. #SoftwareEngineering #DevOps #WebDevelopment #BackendDevelopment #JavaScript #Docker #NodeJS #EngineeringLeadership

I've been thinking for a while about the best way to concurrently work with Claude Code on multiple issues in parallel in the same repo. Git worktrees are cool, but they need to be managed. Additionally, the scripts that setup the new worktree etc need to managed, and also the problem of shared resources (like a web server that is running on only one of the worktrees) needs to be solved. I ended up forking an existing worktree manager into wotr ( https://lnkd.in/dt7Cc6Et ) - a TUI/CLI for agentic worktree management, built in a way that allows to define all the repo-specific script tooling (hooks, actions, and resources) inside a config file in the repo. Also ships with a Claude Code skill that will analyze your repo and create that config file. If you find it useful - awesome. In any case I certainly enjoyed building that...

🚀 Eliminated Merge Conflicts in Our Angular Project — Here’s How Recently, our team was struggling with a common (but painful) problem: ❌ Huge Git diffs ❌ Formatting conflicts during merges ❌ “Who changed this line?” confusion The root cause? 👉 Inconsistent code formatting across developers. 💡 The Solution: Automate Everything We implemented a simple but powerful setup: ✔ Prettier → for consistent formatting ✔ ESLint → for code quality ✔ Husky → to enforce rules before commit ✔ lint-staged → to run checks only on changed files ⚙️ What Changed? Now, whenever a developer commits: 👉 Code is automatically formatted 👉 Lint issues are fixed 👉 Bad code is blocked Result: ✅ Clean Git history ✅ Minimal merge conflicts ✅ Consistent codebase across the team 🧠 Key Learning Don’t rely on developers to follow formatting rules manually. 👉 Automate it at the Git level. 🔥 Pro Tip Do a one-time formatting baseline commit, then enforce rules going forward. After that, your diffs will only show real logic changes — not formatting noise. #Angular #Frontend #CleanCode #ESLint #Prettier #Husky #Git #SoftwareEngineering #DeveloperExperience

How to Install #GitLab on #AlmaLinux #VPS Easily In this tutorial we are going to show you in detail how to install Gitlab on AlmaLinux VPS. What is GitLab? GitLab is open-source #software written in Ruby, Go and JavaScript operated by GitLab Inc. GitLab offers a wide range of features such as CI/CD (Continuous Integration, Continuous Delivery) which makes the work of developers and administrators straightforward and simple. Installing GitLab on AlmaLinux VPS is a straightforward process ... Keep Reading 👉 https://lnkd.in/gQnpmbnG #dedicatedserver #rubyonrails #selfhosted #rubygems #installguide #selfhosting

🚀 Using Git Hooks for Automated Code Quality Checks in Node.js Git hooks are scripts that run automatically before or after Git events, such as commits or pushes. They can be used to automate code quality checks, such as running linters (e.g., ESLint) and unit tests, before allowing code to be committed or pushed. This helps to enforce coding standards and prevent errors from being introduced into the codebase. Git hooks are defined in the `.git/hooks` directory of a Git repository. #NodeJS #Backend #JavaScript #APIs #professional #career #development