Forem: Kelvyn Thai

Stop blindly replacing `enum` with `as const`

Kelvyn Thai — Fri, 13 Mar 2026 07:18:46 +0000

You’ve probably seen many posts suggesting that we should replace TypeScript enum with as const objects because of benefits like:

better tree-shaking
smaller bundle size
less runtime code

That advice is not entirely wrong, but it is often oversimplified.

The real question is not “Should we stop using enums?”
The better question is:

Do we actually understand what TypeScript generates behind the scenes, and what trade-offs we are making?

The key idea: reverse mapping

For numeric enums, TypeScript generates extra runtime code.

enum Direction {
  Up,
  Down,
  Left,
  Right,
}

This is transpiled to JavaScript roughly like this:

var Direction;
(function (Direction) {
  Direction[Direction["Up"] = 0] = "Up";
  Direction[Direction["Down"] = 1] = "Down";
  Direction[Direction["Left"] = 2] = "Left";
  Direction[Direction["Right"] = 3] = "Right";
})(Direction || (Direction = {}));

At first glance, that looks weird.
But here is what is happening:

TypeScript creates an IIFE (Immediately Invoked Function Expression).
It assigns Direction["Up"] = 0.
That assignment returns 0, so TypeScript also sets Direction[0] = "Up".

So at runtime, we get an object like this:

{
  Up: 0,
  Down: 1,
  Left: 2,
  Right: 3,
  0: "Up",
  1: "Down",
  2: "Left",
  3: "Right"
}

This is called reverse mapping.

That means:

Direction.Up // 0
Direction[0] // "Up"

Why some developers prefer `as const`

Now compare that with:

const DirectionConst = {
  Up: "Up",
  Down: "Down",
  Left: "Left",
  Right: "Right",
} as const;

This is just a plain JavaScript object.
No IIFE.
No reverse mapping.
No extra enum runtime emit.

That is why many developers say as const can be better for:

frontend apps
config objects
route names
statuses
action types
other JS-first patterns

But does that mean `enum` is bad?

Not at all.

The real issue is that many people blindly replace enums without understanding the use case.

Because not all enums are the same:

numeric enums generate reverse mapping
string enums do not generate reverse mapping
const enum has a different trade-off again
as const is not a 1:1 replacement for every enum use case

The important takeaway

We should not blindly replace enum with as const just because it is trending.

Instead, we should ask:

Do we need reverse mapping?
Do we need a runtime enum object?
Are we using numeric enums or string enums?
Is this app code, library code, or protocol/compiler-style code?
Are we optimizing for explicitness, bundle size, or JS simplicity?

Final thought

as const is a great pattern.
But enum is not automatically wrong.

The real senior move is not to follow slogans like:

“Stop using enums.”

The real senior move is to understand how TypeScript works behind the scenes and choose the right tool for the right use case.

My Friend Failed an Interview at a Top Company Because of One JavaScript Question: this

Kelvyn Thai — Wed, 04 Mar 2026 09:59:41 +0000

Recently my friend failed an interview at a top tech company.

The interviewer didn't ask about algorithms.
Not about system design.

Just one topic:

The this keyword in JavaScript.

At first glance the questions looked simple.

But they were designed to reveal whether the candidate truly understands runtime binding in JavaScript.

Let's walk through the same interview questions.

The Golden Rule of `this`

Before looking at the questions, remember this rule:

this is determined by how a function is called, not where it is defined.

This single rule explains most this bugs in JavaScript.

Another important rule:

Arrow functions do not have their own this. They capture it from the surrounding scope.

Understanding these two rules is key to solving the following interview questions.

Interview Question 1 — Object Method vs Unbound Function

const module = {
  x: 42,
  getX() {
    return this.x;
  },
  getXLambda: () => this.x
};

console.log(module.getX());
console.log(module.getXLambda());

const unboundGetX = module.getX;
const unboundGetXLambda = module.getXLambda;

console.log(unboundGetX(), unboundGetXLambda());

What many developers answer

Actual result (typical browser environment)

42
undefined
undefined
undefined

Why?

Case 1

module.getX()

This is a method call, so:

this === module

Result:

Case 2

module.getXLambda()

Arrow functions do not bind this to the object.

They capture this from the surrounding scope (usually the global scope).

So:

this !== module

Result:

undefined

Case 3

const unboundGetX = module.getX;
unboundGetX();

Now the function is extracted from the object and called as a plain function.

So:

this === window (browser) or undefined (strict mode)

Result:

undefined

Case 4

Arrow functions still reference the outer scope this, so extracting them does not change behavior.

Result:

undefined

Fix

const boundGetX = module.getX.bind(module);
console.log(boundGetX()); // 42

Interview Question 2 — Callable Function Object

Now the interviewer moved to a slightly trickier example.

type MyNum = {
  scale: number;
  defaultValue: number;
  (): number;
};

const MyNum = function () {
  return this.defaultValue * this.scale;
} as unknown as MyNum;

MyNum.defaultValue = 1;
MyNum.scale = 5;

console.log(MyNum());

What developers expect

Actual result

NaN

Why?

Calling:

MyNum()

is a plain function call, so this becomes the global object (or undefined in strict mode).

The function effectively evaluates:

window.defaultValue * window.scale

Both are undefined.

undefined * undefined → NaN

Arrow Function Version

Some developers try to fix it using an arrow function.

const MyNum = () => {
  return this.defaultValue * this.scale;
};

This still does not work.

Arrow functions capture this from the surrounding scope, not from the function object.

Fix

Bind the function to itself:

const boundMyNum = MyNum.bind(MyNum);
console.log(boundMyNum()); // 5

Interview Question 3 — Old React Class Component Bug

This problem appeared frequently in older React class components.

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  handleClick() {
    this.setState({ count: this.state.count + 1 });
  }

  handleClickLambda = () => {
    this.setState({ count: this.state.count + 1 });
  };

  render() {
    return (
      <div>
        <button onClick={this.handleClick}>
          Normal Function
        </button>

        <button onClick={this.handleClickLambda}>
          Arrow Function
        </button>
      </div>
    );
  }
}

What happens?

For the normal function:

this.handleClick

React extracts the function and executes it like:

callback()

So:

this === undefined

Result:

Cannot read property 'setState' of undefined

Fix

Bind it in the constructor:

this.handleClick = this.handleClick.bind(this);

Why Arrow Functions Work

Arrow functions capture this from the class instance, so:

this === Counter instance

This is why arrow functions became popular in React class components.

Why These Questions Matter

These questions are not about syntax.

They test whether you understand:

runtime binding
callback execution
arrow function lexical this
how JavaScript functions behave when extracted from objects

Frameworks like React, Node.js, and Express rely heavily on callbacks.

If you misunderstand this, subtle bugs appear everywhere.

Final Takeaway

The most important rule to remember:

this depends on how a function is called, not where it is written.

And:

Arrow functions capture this from their surrounding scope.

If you remember these two rules, debugging most this issues becomes much easier.

And in my friend's case, understanding that rule would have made the difference between passing and failing the interview.

What is the diff between `Date` vs `new Date()` or `String` vs `new String()`

Kelvyn Thai — Sat, 07 Feb 2026 14:00:05 +0000

Hi everyone, I'm Kelvyn. Yesterday I did a deep dive regarding the
constructor signature side. Today we will go through this topic to
clarify some questions related to:

1/ What is the diff between new (constructor signature) vs executing a function (call signature)?

2/ Even if we know these definitions, how can we declare their typings in TypeScript?

3/ Even if we understand the diff and know how to declare typings following the docs, why do we have the new keyword? What is an instance? Why do primitives and built-in objects / object prototypes exist?

Great! Let's start.

Prerequisite

If you still haven't read about call constructors, you can quickly
review it here:\
👉 https://dev.to/kelvynthai/build-a-simple-mini-dayjs-clone-logger-middleware-by-call-signatures-in-typescript-8pj

Well, sometimes you might see code like this in your codebase:

new Boolean();
new Date();
new Array();
new Promise(() => {});

We can call these built-in objects in JavaScript, and they are
supported by the runtime environment. But what is really happening
behind the scenes? How do we have them? How do we declare their typings?

1/ What is the diff between `new` (constructor signature) vs executing a function (call signature)?

It's quite simple --- with a constructor signature, we must use the
new keyword. Too easy!

Such as:

new Date();
new Promise(() => {});
new Number();
new Error();

How about the call signature (you can review the call constructor link)?
Examples include dayjs() or logger().

One is executed as a function, the other is used with new.

Sounds good?

2/ How can we declare their typings in TypeScript?

type ConstructDate = {
  new (dateStr: string): string;
};

const main = (constructDate: ConstructDate) => {
  const myConstructDate = new constructDate("Sat 7 Feb 2026");
};

Following this way, we can easily declare typings for a constructor
signature. Too easy, right?

Yeah --- are we done? Can we close the laptop and go to sleep?

But if you're like me and don't understand how to mix call and
constructor signatures, calm down and continue scrolling 🙂

I spent a lot of time reading this in TypeScript, and to be honest, it
was quite confusing. From the call signature, we have clear examples of
how to define it. But with constructors, the docs usually only simplify
the declaration of typings and don't give us a method to implement them.

So let me guide you.

Let's try printing this:

console.log(typeof String); // function
console.log(typeof String.prototype); // object
console.log(typeof new String()); // object

As you can see, the root cause is that using the new keyword returns
an object, not a primitive value. But why is that?

*** Why does new return an object instead of a primitive? ***

Because the purpose of new is to create an instance.

And an instance must be an object so it can:
• hold properties
• inherit methods
• link to a prototype
• support polymorphism

The instanceof operator tests to see if the prototype property of a constructor appears anywhere in the prototype chain of an object. The return value is a boolean value. Its behavior can be customized with Symbol.hasInstance.

A primitive cannot do these things.

So this is not accidental — it is by language design.

Learn more at:

Prototypes are the mechanism by which JavaScript objects inherit features from one another. In this article, we explain what a prototype is, how prototype chains work, and how a prototype for an object can be set.

In JavaScript, we have 3 ways to implement prototype inheritance:
object, constructor, and class. Among these, classes are very
straightforward.

For example:

class Animal {
  eat() {
    console.log("nhoammmm");
  }
}

class Human extends Animal {
  work() {
    console.log("Working and earn money!");
  }
}

const kelvynThai = new Human();

console.log(typeof Human, typeof Human.prototype); // function, object
console.log(kelvynThai instanceof Human); // true
console.log(kelvynThai instanceof Animal); // true
console.log(Object.getPrototypeOf(kelvynThai) === Human.prototype); // true
console.log(Object.getPrototypeOf(Human.prototype) === Animal.prototype); // true
console.log(typeof kelvynThai); // object
kelvynThai.work(); // Working and earn money!
kelvynThai.eat(); // Nhoammmm

Now let's move to constructor inheritance:

function Animal() {}

Animal.prototype.eat = function () {
  console.log("Nhoammmm");
};

function inheritPrototype(proto: unknown) {
  function ChainLink() {}
  ChainLink.prototype = proto;
  return new ChainLink();
}

function Human() {}

Human.prototype = inheritPrototype(Animal.prototype);

Human.prototype.work = function () {
  console.log("Coding and earning money!");
};

const kelvynThai = new Human();
console.log(typeof Human, typeof Human.prototype); // function, object
console.log(kelvynThai instanceof Human); // true
console.log(typeof kelvynThai); // object
console.log(Object.getPrototypeOf(kelvynThai) === Human.prototype); // true
console.log(Object.getPrototypeOf(Human.prototype) === Animal.prototype); // true
kelvynThai.work(); // Coding and earning money!
kelvynThai.eat(); // Nhoammmm

That means our ConstructDate type should be adjusted from the
primitive 'string' → built-in object String.

type MyDate = {
  // eslint-disable-next-line
  new (dateStr: string): String; // constructor -> object
  (dateNum?: number): string; // call -> primitive
};

const MyDate: MyDate = function (this: unknown, d?: string | number) {
  if (new.target) {
    // always ensure constructor returns an object
    return new String(`PARSED_DATE:${d}`);
  }

  return !!d ? `TIMESTAMP:${d}` : "DEFAULT_DATE";
  // OR: throw new TypeError(`Class constructor ShiftedDate cannot be invoked without 'new'`)
} as MyDate;

const dateWithNew = new MyDate("Sat 7 Feb 2026");
// String object

const dateWithoutNew = MyDate(123456);
// primitive string

console.log(dateWithNew, typeof dateWithNew); 
// [String: 'PARSED_DATE:Sat 7 Feb 2026']  object

console.log(dateWithoutNew, typeof dateWithoutNew); 
// TIMESTAMP:123456 string

console.log(new Date(), typeof new Date()); 
// 2026-02-07T13:58:57.212Z object

Conclusion

Understanding the difference between constructor signatures and call
signatures helps us model JavaScript behavior more accurately in
TypeScript.

TypeScript constructor typings become much easier to reason about.

This knowledge is especially useful when:

Reading built-in APIs\
Designing flexible libraries\
Modeling function behaviors in TypeScript\
Understanding how JavaScript works under the hood

Hope this helps clarify the differences. Happy coding 🚀

Build a simple Mini Day.js Clone & Logger Middleware by Call Signatures in TypeScript

Kelvyn Thai — Wed, 04 Feb 2026 05:15:51 +0000

Hi everyone,

Yesterday I spent some time learning more about TypeScript, and I came
across the term "call signature." It's quite helpful when you want
to define something like a logger middleware or understand how libraries
such as dayjs declare their typings.
Source: https://www.typescriptlang.org/docs/handbook/2/functions.html#call-signatures

First, understand that a function is an object

You should know that the typeof a function prototype is object ---
I'm referring to the prototype, not typeof function itself.

If you are not familiar with prototypes, I strongly suggest reading
about them first before continuing (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Advanced_JavaScript_objects/Object_prototypes).

The problem we want to solve

How can we configure a function and then execute it with those
configurations?

This is somewhat similar to a closure, but closures encapsulate
state using variable scope. With a call signature, the state is exposed
outside --- meaning we can mutate the properties if needed.

You might encounter this pattern somewhere in your codebase, especially
in libraries like dayjs or when implementing a logger middleware.

But how do we define it properly in TypeScript?

Call Signatures in TypeScript

In JavaScript, functions can have properties in addition to being
callable.

However, the typical function type syntax does not allow declaring
properties. If we want to describe something callable with
properties, we can use a call signature inside an object type.

Before continuing, it's helpful if you already understand closures or
have used them to encapsulate function state (for example, in React
hooks).

A call signature is similar to a closure --- but the key difference is
that the state lives outside the function, so it can be modified.

Let's look at an example.

Example 1 --- Mini Day.js Clone

type DayJS = {
  timezone: string;
  description: string;
  (date: string | number | Date): string;
};

const dayjs = function (date: string | number | Date) {
  const tz = dayjs.timezone;

  const formatter = new Intl.DateTimeFormat("en-US", {
    timeZone: tz,
    year: "numeric",
    month: "2-digit",
    day: "2-digit",
    hour: "2-digit",
    minute: "2-digit",
    second: "2-digit",
  });

  return formatter.format(new Date(date));
} as DayJS;

dayjs.timezone = "Asia/Ho_Chi_Minh";
dayjs.description = "Mini DayJS clone";

console.log(dayjs("2026-02-04"));
// 02/04/2026, 07:00:00 AM

👉 Here, dayjs is both:

callable like a function\
configurable via properties

This is exactly what a call signature enables.

Example 2 --- Logger Middleware

Now let's implement a logger middleware with configurable properties
such as:

isEnabled (based on production env)
log type (warning, error, info)
message payload

type LoggerData = { message: string; metadata?: unknown };

type LoggerType = "warning" | "error" | "info";

type LoggerMiddleware = {
  isEnabled: boolean;
  type: LoggerType;
  (data: LoggerData): void;
};

const initializedSomeService = () => {
  const warningLogger: LoggerMiddleware = function (data) {
    if (!warningLogger.isEnabled) return;

    console.warn(`TYPE:${warningLogger.type}`, { data });
  };

  // configure properties
  warningLogger.isEnabled = process.env.NODE_ENV === "production";
  warningLogger.type = "warning";

  // execute like a function
  warningLogger({
    message: "This is a warning message",
    metadata: { id: "ab85592d-b7cf-4623-9884-aa70f40814f7" },
  });
};

initializedSomeService();

Result:

TYPE:warning {
  data: {
    message: 'This is a warning message',
    metadata: { id: 'ab85592d-b7cf-4623-9884-aa70f40814f7' }
  }
}

When should you use call signatures?

Use them when you want something that is:

✅ callable like a function\
✅ configurable via properties\
✅ strongly typed

Typical real-world use cases:

logger utilities\
analytics trackers\
feature flag executors\
SDK-style APIs\
libraries like dayjs

Closure vs Call Signature (Quick Insight)

Closure Call Signature

Encapsulates state Exposes state
Safer from mutation Mutable
More functional style More library-style
Common in hooks Common in SDK design

Neither is better --- choose based on your design goal.

If you want immutability → prefer closures.\
If you want configurability → call signatures shine.

Final Thoughts

Call signatures are a small TypeScript feature, but once you understand
them, you'll start noticing this pattern in many libraries.

They provide a powerful way to design APIs that feel natural to
JavaScript --- configurable, callable, and strongly typed.

Definitely worth adding to your TypeScript toolbox 🚀

How to integrate AI Agent Skills to NextJS App & Cursor AI ?

Kelvyn Thai — Thu, 22 Jan 2026 11:48:57 +0000

Hi everyone, I’m Kelvyn, a Software Engineer.

Recently, I’ve been reading many articles related to React Best Practices for AI Agent Skills. This topic is being discussed widely in companies and also appears frequently in my feeds.
So if you’re someone working with Cursor, React, or Next.js, and you’re curious about how to integrate AI Agent Skills into your workflow, this article is for you.

When I first started reading about this topic, I asked myself:

What are AI Agent Skills?
What are the real use cases?
Even if we understand them, how do we integrate them?
And how can we ensure they’re working as expected?

So let’s start by breaking this problem down step by step.

I. Rules vs Skills — Summary

What are Rules?

Rules define the law.
Very straightforward:

Red light → stop
Green light → go

FYI:

Rules provide system-level instructions to an Agent. They bundle prompts, scripts, and more together, making it easy to manage and share workflows across your team.

How Rules Work

Large Language Models don’t retain memory between completions.
Rules provide persistent, reusable context at the prompt level.

When applied, rule contents are included at the start of the model context, giving the AI consistent guidance for:

generating code
interpreting edits
helping with workflows

Examples

“Whenever you write TypeScript, enforce exhaustive handling for union types.”
“UI modules must follow container/presentational separation. Presentational components must be pure (no hooks, no side effects).”
“Enforce a maximum of 100 lines of code per UI file.”
“Enforce .webp format for images.”

What Rules Are

Standards, requirements, and guardrails
Define what must always be true
Shape how the AI reasons and makes decisions

Skills

What Are Skills?

Skills define the method or capability to do something.

FYI:

Agent Skills are an open standard for extending AI agents with specialized capabilities. Skills package domain-specific knowledge and workflows that agents can use to perform specific tasks.

Examples

“How to enforce exhaustiveness in a TypeScript switch.”
“How to refactor a component into container + presentational.”
“How to review a module structure.”

What Skills Are

Named capabilities or playbooks
Teach the AI how to do something well

Rule	Skill
Enforce exhaustive union handling	TS Exhaustive Switch Checking
Enforce container/presentational architecture	Container–Presentational Review & Refactor

II. What Is React Best Practices?

React Best Practices is a structured repository for creating and maintaining React best practices optimized for AI agents and LLMs.

Imagine your team has rules for folder structure:

Enforcing container/presentational patterns
Limiting each feature to 3 files:
- index.ts (exports)
- ComponentName.tsx (UI)
- ComponentName.actions.ts (logic, hooks, queries)

Normally, you’d document this in something like docs/component-structure.md.
Every time you want a code review, you’d need Cursor to re-read that document.

Another example is enforcing exhaustive switch checking for render blocks or feature flags.

So the question is:

Can we make these rules global, reusable, and automatically applied — without re-injecting context every time?

References

Rules file format: https://cursor.com/docs/context/rules#rule-file-format
Rules file structure: https://github.com/vercel-labs/agent-skills/tree/main/skills/react-best-practices#rule-file-structure

III. How to Integrate with a Next.js Application

Prerequisites

Initialize a Next.js app: https://nextjs.org/docs/app/getting-started/installation

Step 1: Set Up React Best Practices

npx add-skill vercel-labs/agent-skills -y

You should see new folders created.

Great! The repository has been cloned successfully.

Reference: https://vercel.com/blog/introducing-react-best-practices

Step 2: Enable “Nightly” Mode in Cursor

Open Cursor Settings

Mac: Cmd + Shift + J
Windows/Linux: Ctrl + Shift + J
1. Navigate to the Beta tab
2. Select Nightly mode

You may need to restart Cursor to ensure it’s enabled.

Step 3: Ensure Skills Are Applied

Open Cursor Settings
Navigate to Rules, Skills, Subagents
Verify skills appear under Agent Decides

Fantastic! We’ve successfully set up AI Agent Skills for a Next.js app.

Reference: https://cursor.com/docs/context/skills

Step 4: Verify That Skills Work

Try a simple prompt:

Review this component

Cursor reports:

✅ No waterfall issues
✅ No bundle size concerns
✅ No re-render issues
✅ No JavaScript performance issues

Looks good — but are we fully convinced?

Step 5: Create a Rule and Test It

Now let’s add a new rule enforcing module structure:

Max 3 files per submodule
Kebab-case naming
Container/presentational pattern
UI must be pure
Logic in .actions.ts(x)
Re-export via index.ts

Rule reference:
https://gitlab.com/kelvyn-labs/nextjs-ai-skills-template/-/blob/main/.agents/skills/vercel-react-best-practices/rules/advanced-module-structure.md

Try again:

Review HomePage.tsx

Hmm… this looks strange.
It seems the new skill wasn’t applied.

Step 6: Integrate `react-best-practices-build`

After reviewing the documentation and source code, it turns out that AGENTS.md and SKILL.md must be regenerated whenever new rules are added.

This step is not clearly mentioned in the official docs.

Clone the repo:

git clone https://github.com/vercel-labs/agent-skills.git

Move the build package into your workspace:

mkdir -p packages
cp -r agent-skills/packages/react-best-practices-build packages/
cp agent-skills/skills/react-best-practices/metadata.json .agents/skills/vercel-react-best-practices
cp agent-skills/skills/react-best-practices/rules/_sections.md \
   agent-skills/skills/react-best-practices/rules/_template.md \
   .agents/skills/vercel-react-best-practices/rules/
rm -rf agent-skills

Update pnpm-workspace.yaml:

packages:
  - packages/*
...

Install dependencies:

cd packages/react-best-practices-build
pnpm install

Update SKILL_DIR:

// packages/react-best-practices-build/src/build.ts
export const SKILL_DIR = join(
  __dirname,
  "../../..",
  ".agents/skills/vercel-react-best-practices"
);

Validate rules:

pnpm validate

Build skills:

pnpm build

Check AGENTS.md:

Final Test

Review this component

NICE!
The new rule is now enforced automatically.

Summary

Rules define what must always be true
Skills define how the AI performs tasks
Custom rules require rebuilding AGENTS.md
Once set up, no extra prompting or context is needed

Full source code:
https://gitlab.com/kelvyn-labs/nextjs-ai-skills-template

Cảm ơn cuộc đời vì mỗi sáng vẫn còn một hơi thở

Kelvyn Thai — Tue, 13 Jan 2026 09:52:27 +0000

Cảm ơn cuộc đời vì mỗi sáng vẫn còn một hơi thở

Vừa rồi tôi bị tức ngực đến mức mỗi lần ngồi vào bàn làm việc là không thể tập trung nổi, cơn đau nhức hành hạ khiến tôi không thở được.

Với một người yêu công việc, thích học cái mới như tôi, đó là một thử thách không hề nhỏ.

Sức khỏe cảnh báo, và tâm cũng bắt đầu lên tiếng.

Suốt một năm qua, buổi tối nào tôi cũng dành cho learning và growing.

Tôi hoàn thành JSNAD (Linux Foundation), GitLab CI Fundamentals, LFW211, Coursera Meta, NestJS…

Tôi viết blog chia sẻ về Yarn → PNPM, optimize Docker image, GitLab CI/CD, Next.js…

Tôi làm tất cả với một niềm tin rất đơn giản:

“Cứ gieo hạt tử tế, rồi sẽ có ngày hái quả.”

Nhưng rồi, đến lúc nhìn lại, tôi nhận ra sức khỏe mình ngày một kém.

Tôi đi khám cả Đông lẫn Tây y.

Khi sức khỏe tạm ổn, tôi cố gắng quay lại công ty.

Và rồi tôi nhận ra một sự thật rất giản dị:

công ty có tôi hay không, mọi thứ vẫn tiếp tục chạy.

Sau một tuần nghỉ rồi trở lại, mọi thứ vẫn như cũ.

Lạ là tôi không buồn.

Tôi chỉ thấy một cảm giác bình an, nhẹ nhõm đến khó tin.

Một cảm giác như thể:

mình không còn gì để mất.

Không còn làm việc để cầu hạnh phúc,

không còn làm để mong được tăng lương, thăng chức,

không còn làm để tìm ánh mắt ngưỡng mộ hay sự công nhận.

Chỉ đơn giản là làm – vì đó là việc mình làm được trong kiếp này.

Mình may mắn hơn rất nhiều người ngoài kia.

Có những người đang thất nghiệp, Tết đến vẫn phải lo từng bữa ăn, từng khoản tiền nhà.

Còn tôi, ít nhất trong giai đoạn này,

vẫn có một công việc để trở về,

một bàn làm việc để ngồi xuống,

và một nhịp sống đủ ổn để không phải hoảng loạn trước ngày mai.

Chừng đó thôi,

đã là một phước lớn.

May mắn là trong khoảng thời gian đó, tôi gặp được Kinh Phổ Môn.

Chỉ vài trang chữ thôi, nhưng mỗi lần đọc, tôi lại ngộ ra rất nhiều điều.

Tôi trước khi đọc Phổ Môn – và sau khi

Trước đây,

khi được khen tôi phấn khích,

khi được tăng lương tôi nghĩ “mình xứng đáng”,

khi bị bỏ qua tôi thấy tức, thấy đau, thấy uất.

Tôi nghĩ:

“Nếu không được thì coi như công cốc.”

Sau khi đọc Phổ Môn,

khi được khen tôi biết đó là duyên,

khi được tăng lương tôi chỉ thấy “duyên đang thuận”,

khi bị bỏ qua tôi tự nhắc mình “duyên chưa chín”.

Và tôi nghĩ khác đi:

“Ta đã gieo, cây đang mọc – dù ai hái trái thì cây vẫn lành.”

Cuối năm nay, tôi mất đi nhiều thứ:

tham lam, ích kỷ, sân si, vô minh.

Nhưng tôi lại được một thứ rất lớn:

một trái tim nhẹ hơn.

Và thế là đủ.

Cảm ơn cuộc đời

vì mỗi sáng

tôi vẫn còn một hơi thở.

How 'never' Type Prevents Broken Code in Production

Kelvyn Thai — Tue, 06 Jan 2026 07:51:26 +0000

Most production bugs don’t come from syntax errors.
They come from valid code paths that nobody noticed.

TypeScript helps a lot — but there’s one class of bugs it does not catch by default, especially in React codebases that evolve over time.

This article shows:

a real React bug that silently ships to production
why TypeScript doesn’t warn you
how the never type turns that bug into a compile-time error

What Is the `never` Type?

In TypeScript, never represents something that cannot happen.

Not “returns nothing”.
Not “empty”.

But this:

A code path that is impossible to reach.

If a value has type never, it means:

there is no possible runtime value
if execution reaches here, something is wrong

Simple Examples

function crash(): never {
  throw new Error("Boom");
}

This function never finishes normally.

function infiniteLoop(): never {
  while (true) {}
}

Execution can never continue past it.

That’s why the return type is never.

The One Rule That Makes `never` Powerful

This rule is the key:

never is assignable to every type,
but no type is assignable to never (except never itself).

Example:

let x: never;

x = "hello"; // ❌ error
x = 123;     // ❌ error

If TypeScript ever sees a real value being assigned to never,
it immediately fails the build.

We’ll use this rule to stop production bugs.

The Setup: A Common React Pattern

Imagine a component that renders UI blocks based on a type field
(CMS blocks, feature flags, workflows — very common).

type Block =
  | { type: "hero"; title: string }
  | { type: "cta"; text: string };

Renderer:

function RenderBlock({ block }: { block: Block }) {
  switch (block.type) {
    case "hero":
      return <h1>{block.title}</h1>;

    case "cta":
      return <button>{block.text}</button>;
  }
}

Everything looks fine:

TypeScript is happy
CI passes
No runtime error

The Production Bug (Silent)

A teammate adds a new block:

type Block =
  | { type: "hero"; title: string }
  | { type: "cta"; text: string }
  | { type: "banner"; image: string };

They forget to update RenderBlock.

What happens?

No TypeScript error
No build failure
No runtime crash

The component returns undefined.
Nothing renders.

Production UI is broken silently.

This is the worst kind of bug.

Why TypeScript Didn’t Save You

From TypeScript’s point of view:

the function might return JSX.Element | undefined
that is technically valid
TypeScript does not assume your switch is exhaustive

So the bug passes.

The Wrong “Fix”

You might add a default:

default:
  return null;

This makes things worse:

still no compiler error
still broken UI
now even harder to notice

We need TypeScript to fail loudly.

Introducing `never`

Now we change one line.

function RenderBlock({ block }: { block: Block }) {
  switch (block.type) {
    case "hero":
      return <h1>{block.title}</h1>;

    case "cta":
      return <button>{block.text}</button>;

    default:
      const _exhaustiveCheck: never = block;
      return null;
  }
}

*The result: *

This line is the key:

const _exhaustiveCheck: never = block;

What Changed?

This line tells TypeScript:

“If block reaches here, this code is wrong.”

When banner exists, TypeScript now sees:

block can be { type: "banner" }
banner is not assignable to never

Compile-time error.
CI fails.
The bug never ships.

The Real Win

This is not about exhaustiveness checking.

It’s about this guarantee:

If the code compiles, all cases are handled.

That’s production safety.

Why This Matters in Real Codebases

This pattern shines when:

CMS schemas evolve
multiple teams touch the same union types
UI rendering depends on configs or API responses
reducers or workflows grow over time

Anywhere types change faster than implementations, never protects you.

Mental Model

never means:
“This code path must not exist.”

If TypeScript ever proves that it can exist,
your build fails — by design.

Conclusion

TypeScript does not guarantee exhaustive handling by default
React components can silently break in production
never turns missing cases into compiler errors
One line prevents an entire class of bugs

const _exhaustiveCheck: never = value;

Use it where silence is dangerous.

Stop trying `typeof x === Fish`: A practical guide to TypeScript type verification (Narrowing + Type Predicates)

Kelvyn Thai — Mon, 05 Jan 2026 14:45:16 +0000

When you come from a “typed mindset”, it’s natural to want something like:

typeof animal === Fish

But JavaScript doesn’t work that way.

1) The key idea: types don’t exist at runtime

TypeScript types are erased after compilation. At runtime, you only have JavaScript values.

So runtime checks are always things like:

typeof x === "string"
x instanceof Date
"swim" in animal
animal.kind === "fish"

TypeScript then uses those checks to narrow union types.

2) Narrowing: TypeScript understands common JS patterns

`typeof` narrowing (primitives)

function padLeft(padding: number | string, input: string) {
  if (typeof padding === "number") return " ".repeat(padding) + input;
  return padding + input;
}

`instanceof` narrowing (classes / constructors)

function logValue(x: Date | string) {
  if (x instanceof Date) return x.toUTCString();
  return x.toUpperCase();
}

`"in"` narrowing (property existence)

type Fish = { swim: () => void };
type Bird = { fly: () => void };

function move(animal: Fish | Bird) {
  if ("swim" in animal) animal.swim();
  else animal.fly();
}

⚠️ Note: in works on the prototype chain and optional props affect both branches.

3) Type predicates: make narrowing reusable (the real win)

Sometimes you want to reuse a check across multiple places (especially in .filter()).

That’s where type predicates (user-defined type guards) shine:

type Fish = { swim: () => void };
type Bird = { fly: () => void };

function isFish(animal: Fish | Bird): animal is Fish {
  return "swim" in animal;
}

function move(animal: Fish | Bird) {
  if (isFish(animal)) animal.swim();
  else animal.fly();
}

Now the same function can be reused:

const zoo: (Fish | Bird)[] = [/* ... */];
const fishes = zoo.filter(isFish); // Fish[]

type ButtonAsLink = { href: string; onClick?: never };
type ButtonAsAction = { onClick: () => void; href?: never };
type Props = { label: string } & (ButtonAsLink | ButtonAsAction);

function isLinkProps(p: Props): p is Props & ButtonAsLink {
  return "href" in p;
}

function SmartButton(props: Props) {
  if (isLinkProps(props)) {
    return <a href={props.href}>{props.label}</a>;
  }
  return <button onClick={props.onClick}>{props.label}</button>;
}

4) Best practice when you control the model: discriminated unions

If you can change the data shape, this is the most robust approach:

type Fish = { kind: "fish"; swim: () => void };
type Bird = { kind: "bird"; fly: () => void };

function move(animal: Fish | Bird) {
  if (animal.kind === "fish") animal.swim();
  else animal.fly();
}

This is clearer than property checks and scales well as unions grow.

5) Common pitfalls (learn these once)

typeof null === "object" (historic JS quirk)
!value checks falsy (0, "", false) — not just null/undefined
"prop" in obj can be true because of prototypes
Optional properties can cause both branches to still include a type (e.g., Human can swim?())

Takeaway

Runtime verification comes from JavaScript checks.
Compile-time safety comes from TypeScript narrowing.
When you want reuse, wrap it in a type predicate.

If you remember one line:

“Use JS checks to narrow, and type predicates to reuse the narrowing.”

GitLab CI/CD for Next.js — Part 2: Build Job Setup & Docker Image Caching

Kelvyn Thai — Mon, 29 Dec 2025 04:31:38 +0000

Hi everyone 👋

I’m Kelvyn, a Frontend Engineer with 8 years of experience, mainly working with React and Next.js.

In this series, I’ll walk you through how to set up a comprehensive, production-grade GitLab CI/CD pipeline for a Next.js application, based on real-world experience running CI/CD at scale.

In Part 2, we’ll focus on building a fast and reliable build pipeline, including:

Setting up Docker jobs with docker-cli and docker-dind (Docker BuildKit)
Authenticating with GitLab Dependency Proxy and GitLab Container Registry
Building images with docker buildx, tagging, and caching strategies
Separating environments (production, staging, development)
Running GitLab CI/CD in a cost-efficient way

If you haven’t read it yet, you may want to start with:

👉 GitLab CI/CD for Next.js — Part 0: Project & Repository Setup
👉 GitLab CI/CD for Next.js — Part 1: Validate Job Lint & Check Types

I. Set up Docker jobs with docker-cli and docker-dind

In this section, we set up a reusable Docker job template using docker-cli and docker-dind.
This template will be reused later to build and push Docker images using Docker BuildKit.

Files involved

templates/docker-job.yml Defines a shared Docker job template used by build jobs.

References

`templates/docker-job.yml`

---
.docker-job:
  image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/docker:24.0.5-cli
  services:
    - name: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/docker:24.0.5-dind
      alias: docker
  before_script:
    - echo "Authenticate with Dependency Proxy"
    - echo "$CI_DEPENDENCY_PROXY_PASSWORD" | docker login \
        $CI_DEPENDENCY_PROXY_SERVER \
        -u $CI_DEPENDENCY_PROXY_USER \
        --password-stdin

    - echo "Authenticate with GitLab Container Registry"
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY

Breakdown

`CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`

https://docs.gitlab.com/user/packages/dependency_proxy/

Allows GitLab CI to pull base images and cached layers via GitLab Dependency Proxy, instead of directly from Docker Hub.

Benefits:

Avoids Docker Hub rate limits
Improves image pull speed
Increases pipeline reliability

`CI_REGISTRY`

https://docs.gitlab.com/ci/docker/using_buildkit/#authenticate-with-the-gitlab-container-registry

Used to push and pull Docker images from the GitLab Container Registry.

This enables:

Reusing images across jobs (build → test → deploy)
Treating Docker images as deployable artifacts
Immutable image tagging per environment for better caching

II. Set up build job with Docker buildx

In this section, we set up a build job using Docker Buildx.

Files involved

templates/build-job.yml
Defines a build job template.
Dockerfile
Defines a Dockerfile with multi-layer caching, encapsulating our application.

References

`templates/build-job.yml`

---
include:
  - local: "templates/docker-job.yml"
.build_job:
  stage: build
  variables:
    IMAGE_TAG: $CI_REGISTRY_IMAGE:tag-$CI_COMMIT_REF_SLUG-$CI_COMMIT_SHORT_SHA
    DOCKER_TLS_CERTDIR: "/certs"
  extends:
    - .docker-job
  script:
    - |
      echo "Environment: $ENV"
      echo "Image tag: $IMAGE_TAG"
      echo "CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX: ${CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX}"

    - docker context create buildx-context
    - docker buildx create buildx-context --name builder --bootstrap --driver \
        docker-container --platform linux/amd64 --use
    - docker buildx inspect --bootstrap
    - |
      docker buildx build \
        --platform linux/amd64 \
        --build-arg BUILD_ENV=$ENV \
        --build-arg CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=$CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX \
        --file Dockerfile \
        --tag $IMAGE_TAG \
        --push .
  after_script:
    - docker buildx rm builder
    - docker context rm buildx-context

Breakdown

Docker BuildKit

BuildKit is an improved backend that replaces the legacy Docker builder. It is the default builder for users on Docker Desktop and Docker Engine as of version 23.0.

Docker Buildx extends the Docker CLI to leverage the BuildKit engine, providing enhanced features such as better caching, multi-platform build execution, and builder instance control.

If you want to compare building with and without BuildKit, you can run the following command:
DOCKER_BUILDKIT=0 docker build -t nextjs-cicd-template-image .

IMAGE_TAG

Defines the image tag artifact for our application, allowing it to be reused in other jobs (E2E tests, deployment, etc.).

The format will look like:

registry.gitlab.com/your-group/nextjs-cicd-template:tag-v1-0-33-d34e872b

III. Set up GitLab CI job

In this section, we set up a simple build job to quickly test the pipeline.

Files involved

.gitlab-ci.yml Defines the GitLab CI configuration for our repository.

include:
  # ... existing config
  - local: "templates/build-job.yml" # add build job template

# Build Dev
build_dev:
  extends:
    - .build_job
    - .rules_dev
  variables:
    ENV: "dev"

# Build Staging
build_staging:
  extends:
    - .build_job
    - .rules_staging
  variables:
    ENV: "staging"

# Build Production
build_prod:
  extends:
    - .build_job
    - .rules_prod
  variables:
    ENV: "prod"

Great! Let’s commit the code and run our build job.

As a result, the job completed in ~1.47s, and the script execution time was ~1.19s. Fantastic!

In practice, we usually focus on the script execution time, because the total job duration can include runner scheduling and time spent waiting for cloud resources to be allocated.

IV. Set up Docker Image Caching

In this section, we’ll take advantage of Docker Buildx caching to speed up subsequent builds.

Files involved

templates/build-job.yml Defines a build job template.

References

GitLab Docker Buildx Caching

Let’s modify our build job template and .gitlab-ci.yml to enable cache.

`.gitlab-ci.yml`

Define a cache image per environment (dev, staging, production):

# Build Dev
build_dev:
  # ...
  variables:
    ENV: "dev"
    CACHE_IMAGE: $CI_REGISTRY_IMAGE:cache-dev # cache image tag for dev

# Build Staging
build_staging:
  # ...
  variables:
    ENV: "staging"
    CACHE_IMAGE: $CI_REGISTRY_IMAGE:cache-staging # cache image tag for staging
  needs:
    - test_staging

# Build Production
build_prod:
  # ...
  variables:
    ENV: "prod"
    CACHE_IMAGE: $CI_REGISTRY_IMAGE:cache-prod # cache image tag for production

`templates/build-job.yml`

---
include:
  - local: "templates/docker-job.yml"

.build_job:
  # ...
  script:
    - |
      echo "Environment: $ENV"
      echo "Image tag: $IMAGE_TAG"
      echo "Cache image: $CACHE_IMAGE"
      echo "CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX: ${CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX}"

    - docker context create buildx-context
    - docker buildx create buildx-context --name builder --bootstrap --driver \
        docker-container --platform linux/amd64 --use
    - docker buildx inspect --bootstrap

    - |
      # Use BuildKit registry cache (pull + push)
      docker buildx build \
        --platform linux/amd64 \
        --build-arg BUILD_ENV=$ENV \
        --build-arg CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=$CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX \
        --file Dockerfile \
        --tag $IMAGE_TAG \
        --cache-from type=registry,ref=$CACHE_IMAGE \
        --cache-to type=registry,ref=$CACHE_IMAGE,mode=max \
        --push .

  after_script:
    - docker buildx rm builder
    - docker context rm buildx-context

Breakdown

`CACHE_IMAGE`

We create three separate cache tags, one per environment (dev, staging, prod).
This avoids cache pollution and prevents cross-environment interference (e.g., different dependencies or build settings). Each environment owns its own cache image.

`--cache-from` and `--cache-to`

--cache-from type=registry,ref=$CACHE_IMAGE pulls cached layers from the registry.
--cache-to type=registry,ref=$CACHE_IMAGE,mode=max pushes the updated cache back to the registry to speed up future builds.

Let’s wrap up and commit our code to see what happens!

On the first run, the build will take longer because BuildKit needs to generate the cache and push it to the registry. You may also see a warning like:

ERROR: failed to configure registry cache importer: registry.gitlab.com/your-group/nextjs-cicd-template:cache-dev: not found

That’s expected, because the cache image doesn’t exist yet.

You can navigate to Deploy → Container Registry → nextjs-cicd-template to check the cache image size.

Now, let’s run the pipeline again!

As a result, thanks to caching, the script execution time dropped to ~1m (about 15–20% faster), and the total job time was ~1.27m. Great!

In reality, smaller images not only benefit the build job, but also deployment and E2E testing of your application. Smaller images mean faster pull times.

Summary (Part 2 Recap)

In Part 2 of this series, we built a production-grade Docker build pipeline for a Next.js application using GitLab CI/CD and Docker Buildx, with a strong focus on performance, reliability, and scalability.

We covered:

Reusable Docker job templates using docker-cli and docker-dind, enabling Docker BuildKit in GitLab CI.
Secure authentication with GitLab Dependency Proxy and GitLab Container Registry to improve reliability and avoid Docker Hub rate limits.
Docker Buildx-based build jobs, allowing better caching, multi-platform support, and controlled builder instances.
Environment-based builds (dev, staging, production) with isolated configurations and immutable image tagging.
Registry-based BuildKit caching, using --cache-from and --cache-to, significantly reducing build times after the first run.
Practical insights into CI performance metrics, highlighting why script execution time matters more than total job duration.

By introducing environment-specific cache images, we avoided cache pollution while achieving 15–20% faster builds on subsequent runs.
Beyond CI speed, smaller and well-cached images also improve deployment speed and E2E testing performance due to faster image pulls.

In the next part, we’ll continue building on this foundation to further optimize and productionize the pipeline.

Full source code:
https://gitlab.com/kelvyn-labs/nextjs-cicd-template

GitLab CI/CD for Next.js — Part 1: Validate Job Lint & Check Types

Kelvyn Thai — Mon, 22 Dec 2025 03:16:10 +0000

Hi everyone 👋

I’m Kelvyn, a Frontend Engineer with 8 years of experience, mainly working with React and Next.js.

In this series, I’ll walk you through how to set up a comprehensive, production-grade GitLab CI/CD pipeline for a Next.js application, based on real-world experience running CI/CD at scale.

In Part 1, we’ll focus on building a fast and safe validation pipeline, including:

Linting
Type checking
Environment-aware caching with PNPM
Cost-efficient GitLab CI/CD execution

If you haven’t read it yet, you may want to start with:

👉 GitLab CI/CD for Next.js — Part 0: Project & Repository Setup

I. Setting up validation jobs (linting, type checking)

We’ll start by preparing the following files:

.gitlab.yml
Defines the CI pipeline and validation jobs at the project root.
templates/node-job.yml
Prepares the Node.js Alpine image and sets up PNPM store caching.

References

`.gitlab.yml`

---
stages:
  - validate

include:
  - local: "templates/node-job.yml"

validate:
  stage: validate
  extends: .node-job # inherit from node-job template
  needs: []          # trigger this job immediately
  script:
    - pnpm install --frozen-lockfile --ignore-scripts --prefer-offline
    - pnpm lint
    - pnpm check-types

At this point, we have a basic validation pipeline that ensures code quality before moving forward.

`templates/node-job.yml`

References

---
.node-job:
  image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/node:22.20.0-alpine3.22
  variables:
    PNPM_STORE_KEY: $CI_PROJECT_DIR/.pnpm-store
  before_script:
    - corepack enable && corepack prepare pnpm@10 --activate
    - pnpm --version
    - pnpm config set store-dir $PNPM_STORE_KEY
    - export PNPM_HOME="$CI_PROJECT_DIR/.pnpm"
    - export PATH="$PNPM_HOME:$PATH"

Great! Our validation job is now set up successfully.
Let’s commit the code and run the first pipeline.

The pipeline finishes in 36 seconds, with dependency installation taking roughly ~8.1 seconds 👍

Next, we’ll improve this further by introducing GitLab CI/CD caching together with environment-based variables to avoid cache conflicts or accidental mutations between development, staging, and production.

In real projects, CI/CD cost and execution time matter.
Running validation on every commit quickly becomes noisy, slow, and expensive.

NEW: Create `templates/rules.yml`

Reference

Semantic Versioning

---
.rules_dev:
  rules:
    - if: $CI_COMMIT_REF_SLUG == "develop"

.rules_staging:
  rules:
    - if: $CI_COMMIT_TAG =~ /^staging-\d+\.\d+\.\d+$/

.rules_prod:
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/

.rules_protected:
  rules:
    - if: '$CI_COMMIT_REF_SLUG == "develop"'
    - if: '$CI_COMMIT_TAG =~ /^staging-\d+\.\d+\.\d+$/'
    - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/'

We define a few rules to control when CI/CD jobs should run.

The validation jobs will only be triggered when:

Code is merged into the develop branch
A staging tag is created (e.g. staging-1.0.0)
A production tag is created (e.g. v1.0.0)

In all other cases, the pipeline won’t run — helping us save CI minutes and reduce unnecessary cost.

Update: `.gitlab.yml`

---
include:
  - local: "templates/node-job.yml"
  - local: "templates/rules.yml" # include rules template

# Convert validate job into a reusable template
.validate_job:
  stage: validate
  # old config...
  cache:
    policy: pull-push # allow validate jobs to revalidate cache when needed

# Validate Dev
validate_dev:
  extends:
    - .validate_job
    - .rules_dev
  variables:
    ENV: "dev"

# Validate Staging
validate_staging:
  extends:
    - .validate_job
    - .rules_staging
  variables:
    ENV: "staging"

# Validate Prod
validate_prod:
  extends:
    - .validate_job
    - .rules_prod
  variables:
    ENV: "prod"

We now define separate validation jobs for each environment:

Each job:

Runs only when the correct branch or tag is used
Uses environment-specific variables for isolation
Prevents PNPM cache pollution across environments

Update: `templates/node-job.yml` (cache configuration)

---
.node-job:
  image: ${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/node:22.20.0-alpine3.22
  cache:
    key:
      files:
        - pnpm-lock.yaml
      prefix: $ENV
    paths:
      - $PNPM_STORE_KEY
    policy: pull

Breakdown

PNPM store caching We cache the PNPM store, which contains all downloaded dependencies. We do not cache node_modules because compressing and transferring it is expensive and often slower.

If you want to understand why PNPM works so well, check out:
👉 PNPM Content-Addressable Store Looks Broken on macOS

Default cache policy: pull
Jobs extending node-job can read from the cache only, preventing accidental cache mutation.
Cache prefix: $ENV
Scopes caches by environment (dev / staging / prod) to avoid conflicts and concurrency issues.
Cache files: pnpm-lock.yaml
Cache is revalidated only when dependencies change, keeping it stable and predictable.
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX
Allows GitLab to pull images and cached layers directly from the GitLab registry, instead of hitting Docker Hub or AWS ECR.
https://docs.gitlab.com/user/packages/dependency_proxy/

Let’s commit the code and review the cache behavior.

The pipeline now finishes slightly slower on the first run (~41s) because the cache needs to be downloaded, extracted, and pushed.

However, pay attention to the dependency installation time: ~2.1 seconds 🚀
That’s more than 4× faster compared to no caching.

As the project grows and node_modules becomes larger, this approach can save significant CI time and cost, especially when reused across unit tests, E2E tests, and future pipeline stages.

Summary

In Part 1, we focused on building a fast, safe, and cost-efficient validation pipeline for a Next.js application using GitLab CI/CD.

Here’s what we achieved:

✅ Set up linting and type checking as early validation gates
✅ Introduced reusable CI templates using extends
✅ Applied rule-based execution to run pipelines only on meaningful events (develop, staging, production)
✅ Implemented environment-aware PNPM store caching to avoid cache pollution
✅ Leveraged GitLab Dependency Proxy to reduce external registry traffic
✅ Reduced dependency installation time from ~8s → ~2s, saving CI time and cost

This foundation ensures that only high-quality, type-safe code moves forward — without wasting CI minutes on every commit.

What’s Next — Part 1.1: Unit Testing at Scale 🚀

In Part 1.1, we’ll level up the pipeline by introducing fast and scalable unit testing using Vitest.

We’ll cover:

Setting up Vitest in GitLab CI/CD
Running unit tests in parallel
Test sharding to split large test suites across multiple jobs
Reusing the PNPM store cache to keep test jobs blazing fast
Reducing total pipeline time as the codebase grows

By the end of Part 1.1, you’ll have a production-ready testing pipeline that scales smoothly with your application — without sacrificing speed or cost.

👉 Stay tuned for GitLab CI/CD for Next.js — Part 1.1: Unit Testing with Vitest

*Full source code: *
https://gitlab.com/kelvyn-labs/nextjs-cicd-template

GitLab CI/CD for Next.js — Part 0: Project & Repository Setup

Kelvyn Thai — Fri, 19 Dec 2025 07:31:50 +0000

Hi everyone 👋
I’m Kelvyn, a Frontend Engineer with 8 years of experience, mainly working with React.

In this series, I’ll walk you through how to set up a comprehensive GitLab CI/CD pipeline for a Next.js application, based on real-world production experience.

Who is this article for?

This article is best suited for engineers with 5+ years of experience who want to deep dive into how a modern application is built, tested, and deployed in a structured and scalable way.

It will be much easier to follow if you already have some basic knowledge of:

GitLab CI/CD: GitLab Runner, executors (Shell, Docker), cache, artifacts, container/package registry, templates, components
Docker: Docker daemon, Docker Compose, Docker Buildx
Linux: Ubuntu, AMD64 architecture, CLI, Shell, Vim, SSH
YAML:

What we’ll do in Part 0

In this first part, we’ll focus on:

Initialize repository
Initialize our Next.js application

I. Initialize repository
To get started, create a new GitLab group:
https://gitlab.com/groups/new#create-group-pane

Next, create a blank project named nextjs-cicd-template inside the group.

From the default main branch, create the following branches:

master
staging
develop

II. Initialize the Next.js application**

Initialize a fresh Next.js app inside the project directory:

cd nextjs-cicd-template pnpm create next-app@latest ./ --yes

Next, add a TypeScript type-checking script to your package.json:

"check-types": "tsc --noEmit"
Finally, verify that linting and type checking work as expected:

pnpm lint && pnpm check-types
If both commands pass, we’re ready to move on and integrate these checks into our GitLab CI pipeline.

Remember generate pnpm-lockfile.yaml in order to use at step setup job on Gitlab CI/CD

What’s next?

In Part 1, we’ll set up:
Linting & type-checking jobs
PNPM store caching
GitLab Dependency Proxy
Secure and repeatable validation pipelines
https://dev.to/kelvynthai/gitlab-cicd-for-nextjs-part-1-validate-job-lint-check-types-5dp8

*Full source code: *
https://gitlab.com/kelvyn-labs/nextjs-cicd-template

Which DevOps certs are necessary for a Frontend Lead?

Kelvyn Thai — Fri, 14 Nov 2025 08:03:26 +0000

Hi everyone, I’m Kelvyn, 30 years old.
I’ve been working as a Senior Frontend Engineer (React, Next.js,...) for ~8 years. Recently I’ve been spending more time expanding my DevOps knowledge.

Even though my long-term direction is Frontend Lead / Frontend Platform / Frontend Architecture (not DevOps Engineer), I’ve realized that modern FE teams still need strong DevOps literacy:

Linux
Dockerizing Next.js
Gitlab CI/CD pipelines, Gitlab runner, manage jobs,...
S3 / CloudFront / ECR deployments
Performance, cache, observability
Edge/serverless architectures
K8s
Terraform for provisioning FE infra

So I’m exploring which DevOps or cloud certifications are genuinely useful for a Frontend leader, not someone aiming to become DevOps/Infra.

Here’s what I’m considering some certs from Linux Foundation:

📌 My Shortlist

LFCA (Linux + cloud + DevOps fundamentals)
KCNA (lightweight K8s & cloud-native literacy)
AWS Developer Associate (seems highly relevant for FE deployments)

If you were a Frontend Lead / FE Architect / FE Platform engineer,
or if you've walked a similar path:

👉 Which DevOps/cloud certification actually helped you?
👉 Which ones were not worth it?
👉 What would you learn if you were rebuilding your career today?

I’d really appreciate any insight or personal experience — especially from FE leads who integrate DevOps into their workflow without going full-time infra.

Thanks so much!

Forem: Kelvyn Thai

Stop blindly replacing `enum` with `as const`

The key idea: reverse mapping

Why some developers prefer as const

But does that mean enum is bad?

The important takeaway

Final thought

My Friend Failed an Interview at a Top Company Because of One JavaScript Question: this

The Golden Rule of this

Interview Question 1 — Object Method vs Unbound Function

What many developers answer

Actual result (typical browser environment)

Why?

Case 1

Case 2

Case 3

Case 4

Fix

Interview Question 2 — Callable Function Object

What developers expect

Actual result

Why?

Arrow Function Version

Fix

Interview Question 3 — Old React Class Component Bug

What happens?

Fix

Why Arrow Functions Work

Why These Questions Matter

Final Takeaway

What is the diff between `Date` vs `new Date()` or `String` vs `new String()`

Prerequisite

1/ What is the diff between new (constructor signature) vs executing a function (call signature)?

2/ How can we declare their typings in TypeScript?

Conclusion

Build a simple Mini Day.js Clone & Logger Middleware by Call Signatures in TypeScript

First, understand that a function is an object

The problem we want to solve

Call Signatures in TypeScript

Example 1 --- Mini Day.js Clone

Example 2 --- Logger Middleware

When should you use call signatures?

Closure vs Call Signature (Quick Insight)

Final Thoughts

How to integrate AI Agent Skills to NextJS App & Cursor AI ?

I. Rules vs Skills — Summary

What are Rules?

How Rules Work

Examples

What Rules Are

Skills

What Are Skills?

Examples

What Skills Are

II. What Is React Best Practices?

References

III. How to Integrate with a Next.js Application

Prerequisites

Step 1: Set Up React Best Practices

Step 2: Enable “Nightly” Mode in Cursor

Step 3: Ensure Skills Are Applied

Step 4: Verify That Skills Work

Step 5: Create a Rule and Test It

Step 6: Integrate react-best-practices-build

Final Test

Summary

Cảm ơn cuộc đời vì mỗi sáng vẫn còn một hơi thở

Cảm ơn cuộc đời vì mỗi sáng vẫn còn một hơi thở

Tôi trước khi đọc Phổ Môn – và sau khi

How 'never' Type Prevents Broken Code in Production

What Is the never Type?

Simple Examples

The One Rule That Makes never Powerful

The Setup: A Common React Pattern

The Production Bug (Silent)

Why TypeScript Didn’t Save You

The Wrong “Fix”

Introducing never

What Changed?

The Real Win

Why some developers prefer `as const`

But does that mean `enum` is bad?

The Golden Rule of `this`

1/ What is the diff between `new` (constructor signature) vs executing a function (call signature)?

Step 6: Integrate `react-best-practices-build`

What Is the `never` Type?

The One Rule That Makes `never` Powerful

Introducing `never`

`typeof` narrowing (primitives)

`instanceof` narrowing (classes / constructors)

`"in"` narrowing (property existence)

`templates/docker-job.yml`

`CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`

`CI_REGISTRY`

`templates/build-job.yml`

`.gitlab-ci.yml`

`templates/build-job.yml`

`CACHE_IMAGE`

`--cache-from` and `--cache-to`

`.gitlab.yml`

`templates/node-job.yml`

NEW: Create `templates/rules.yml`

Update: `.gitlab.yml`

Update: `templates/node-job.yml` (cache configuration)