Cách nâng NestJS 7 lên 11 bằng AI mà không đổi logic code

Khi nào nên nâng NestJS cũ bằng AI theo cách này

Nếu bạn đang có một service NestJS cũ, ví dụ NestJS 7, và muốn đưa nó lên NestJS 11, thì cách dễ chết nhất là:

• upgrade tất cả package một lần
• đưa code cho AI sửa hàng loạt
• merge ngay vì thấy build qua

Cách đó thường làm project:

• build được nhưng lệch logic
• pass compile nhưng sai runtime
• đổi luôn cả code style lẫn kiến trúc
• rất khó biết lỗi xuất hiện từ bước nào

Bài này đi theo hướng ngược lại:

• dùng AI để giảm lỗi thao tác
• nhưng vẫn giữ quyền kiểm soát ở phía dev
• chỉ nâng những thứ cần thiết
• và không để AI tự ý đổi logic nghiệp vụ

Mình đã dùng cách này để nâng hơn 10 service lớn từ NestJS 7 lên 11 mà không làm ảnh hưởng hệ thống.

Kết luận nhanh

Nếu cần chốt ngắn gọn:

1. đừng nhảy thẳng từ NestJS 7 lên 11
2. nâng theo từng major: 7 -> 8 -> 9 -> 10 -> 11
3. trước mỗi bước, liệt kê package nào thật sự cần nâng
4. yêu cầu AI chỉ sửa phần cần thiết để pass version mới
5. bắt AI check kỹ những package có breaking change lớn như TypeORM 0.2 -> 0.3
6. luôn dùng git diff hoặc commit theo từng bước để soi thay đổi
7. test lại sau mỗi major version trước khi đi tiếp

Nếu bạn bỏ qua 3 điều này:

• nâng theo từng major
• review diff bằng git
• test lại sau mỗi bước

thì AI càng mạnh, project càng dễ vỡ mà bạn không biết vỡ từ đâu.

Mục tiêu đúng khi nhờ AI nâng NestJS

Khi giao việc này cho AI, mục tiêu không phải là:

• “hãy nâng project này lên bản mới nhất”

Mục tiêu đúng phải là:

• chỉ nâng những package cần thiết của NestJS
• giữ nguyên logic code
• không tự refactor kiến trúc nếu không bắt buộc
• chỉ sửa những chỗ bị breaking change
• ghi rõ file nào đổi và vì sao đổi

Nói cách khác:

• AI ở đây là thợ phụ nâng version
• không phải kiến trúc sư được quyền viết lại hệ thống

Đừng nâng NestJS 7 lên 11 trong một bước

Đây là nguyên tắc quan trọng nhất.

Nếu project đang ở NestJS 7, hãy đi theo thứ tự:

1. 7 -> 8
2. ổn định, test lại
3. 8 -> 9
4. ổn định, test lại
5. 9 -> 10
6. ổn định, test lại
7. 10 -> 11

Lý do:

• mỗi major version có breaking change riêng
• nếu nhảy thẳng nhiều version, diff sẽ rất lớn
• AI rất dễ sửa luôn các phần không liên quan
• khi lỗi xuất hiện, bạn không biết nó bắt đầu từ version nào

Nâng từng bậc giúp bạn:

• khoanh vùng lỗi tốt hơn
• rollback dễ hơn
• review diff dễ hơn
• test có ý nghĩa hơn

Trước khi nâng, hãy liệt kê đúng package cần động vào

Đừng để AI tự nhìn package.json rồi update cả thế giới.

Trước tiên bạn nên liệt kê rõ:

• @nestjs/common
• @nestjs/core
• @nestjs/platform-express hoặc @nestjs/platform-fastify
• @nestjs/testing
• @nestjs/swagger
• @nestjs/config
• @nestjs/microservices
• @nestjs/schedule
• @nestjs/cache-manager hoặc CacheModule liên quan

Ngoài ra còn nhóm package liên đới có thể phải đổi theo:

• rxjs
• class-validator
• class-transformer
• reflect-metadata
• typescript
• typeorm

Không phải project nào cũng cần nâng tất cả cùng lúc. Nhưng bạn phải biết package nào:

• là core của Nest
• là package phụ của Nest
• là package ngoài nhưng có thể vỡ theo major upgrade

Những package cần bắt AI check thật kỹ

1. TypeORM 0.2.x -> 0.3.x

Đây là một trong những cú breaking change lớn nhất khi nâng các project Nest cũ.

Ví dụ với TypeORM 0.2.29 -> 0.3.x, bạn thường sẽ phải đổi:

• Connection sang DataSource
• custom repository pattern cũ
• cách inject repository ở một số project
• config datasource
• cách chạy migration / CLI
• một số cú pháp findOne và option query

Điểm nguy hiểm là:

• AI có thể sửa cho compile qua
• nhưng lại vô tình đổi hành vi query hoặc lifecycle khởi tạo database

Vì vậy với TypeORM, prompt cho AI phải chặt:

• chỉ sửa phần tương thích với 0.3
• không đổi business query nếu không bắt buộc
• nếu query cần đổi syntax thì phải giữ nguyên intent

2. CacheModule và TTL

Một chỗ rất dễ lỗi âm thầm là cache TTL.

Theo docs Nest hiện tại, các API cache mới dùng TTL theo milliseconds ở nhiều chỗ. Nếu project cũ của bạn đang quen nghĩ TTL là giây, AI rất dễ giữ nguyên số cũ nhưng đổi nghĩa runtime.

Ví dụ:

• trước đây bạn nghĩ 60 là 60 giây
• sau nâng cấp, chỗ đó có thể đang được hiểu là 60 milliseconds

Đây là kiểu bug cực khó thấy nếu chỉ nhìn compile.

Vì vậy với cache:

• bắt AI tìm toàn bộ chỗ set ttl
• ghi rõ chỗ nào đang dùng seconds, chỗ nào đang dùng milliseconds
• không được đổi im lặng

3. Swagger, validation và decorator package

Khi nâng nhiều đời Nest, các package như:

• @nestjs/swagger
• class-validator
• class-transformer

cũng có thể tạo ra khác biệt ở:

• schema generate
• decorator behavior
• transform request body
• default validation options

Đây không phải lúc nào cũng là lỗi compile, nhưng rất dễ thành lỗi contract API.

Trước khi chạy AI, nên chuẩn bị những gì

Một flow an toàn là:

1. tạo branch riêng cho việc nâng cấp
2. backup package.json và lock file
3. chụp snapshot test hiện tại
4. nếu chưa có test tự động đủ tốt, ít nhất phải có checklist manual test
5. commit trạng thái hiện tại trước khi sửa gì

Ví dụ:

git checkout -b upgrade/nestjs-7-to-8
git add .
git commit -m "chore: snapshot before upgrading nestjs 7 to 8"

Sau đó mới bắt đầu nhờ AI hỗ trợ.

Prompt nên giao cho AI như thế nào để không làm lệch logic

Đừng prompt chung chung.

Một prompt tốt hơn sẽ giống kiểu:

Project này đang ở NestJS 7.

Mục tiêu hiện tại chỉ là nâng lên NestJS 8.
Chỉ sửa những phần bắt buộc để tương thích version mới.
Không đổi logic business.
Không refactor kiến trúc.
Không đổi tên function, class hoặc folder nếu không bắt buộc.

Hãy liệt kê trước:
1. package NestJS nào cần nâng
2. package phụ nào có thể bị ảnh hưởng
3. breaking change nào cần kiểm tra thủ công

Sau đó mới đề xuất diff nhỏ nhất có thể.

Nếu project có TypeORM hoặc cache, nên thêm:

Project đang dùng TypeORM 0.2.x và cache TTL cũ.
Hãy check kỹ các breaking change liên quan đến DataSource, repository API, migration config và TTL.
Nếu không chắc hành vi cũ, hãy đánh dấu để review thủ công thay vì tự sửa đoán.

Cách nâng từng major version bằng AI

Bước 1: Nâng NestJS từ 7 lên 8

Mục tiêu ở bước này là:

• chỉ chạm phần cần thiết để lên 8
• không nghĩ tới 9, 10, 11 vội

Quy trình:

1. nâng version package mục tiêu
2. cài lại dependency
3. chạy AI để sửa compile error và breaking change bắt buộc
4. đọc git diff
5. chạy test
6. chạy manual smoke test
7. commit lại khi thấy ổn

Ví dụ:

git checkout -b upgrade/nestjs-7-to-8
npm install
npm test
git diff
git add .
git commit -m "chore: upgrade nestjs from 7 to 8"

Bước 2: Chỉ lên 9 khi bản 8 đã ổn định

Đây là chỗ nhiều người nóng vội.

Nếu NestJS 8 vừa compile xong nhưng:

• test chưa chạy đủ
• cache chưa verify
• swagger chưa check
• query database chưa smoke test

thì chưa nên đi tiếp.

Version kế tiếp chỉ nên bắt đầu khi:

• build ổn
• test ổn
• flow chính của service ổn
• diff của bước trước đã được review

Làm tương tự cho:

• 8 -> 9
• 9 -> 10
• 10 -> 11

Luôn bật git để soi thay đổi của AI

Đây là nguyên tắc bắt buộc.

AI sửa nhanh, nhưng cũng rất dễ:

• đổi import không cần thiết
• đổi style code hàng loạt
• đụng vào file không liên quan
• sửa quá tay một đoạn logic chỉ vì muốn pass type

Bạn phải ép quy trình review bằng git.

Tối thiểu nên soi:

• file nào đổi
• package nào đổi
• đoạn nào chỉ là rename API
• đoạn nào có nguy cơ đổi runtime behavior

Các lệnh nên dùng nhiều:

git diff
git diff --stat
git status

Nếu diff quá lớn, đừng merge.

Hãy quay lại và bắt AI làm lại với phạm vi nhỏ hơn.

Những thay đổi cần review thủ công kỹ nhất

Khi AI sửa xong, các chỗ sau phải review thủ công:

• config bootstrap
• global pipe / filter / interceptor
• cache TTL
• database connection init
• repository logic
• migration command
• auth guard
• swagger decorator
• custom decorator
• custom exception filter

Đây là những khu vực rất hay:

• compile qua
• nhưng runtime hoặc hành vi API bị đổi

Sau mỗi bước nâng, phải test lại gì

Đừng đợi tới NestJS 11 rồi mới test.

Sau mỗi major version, nên test lại:

• app có boot lên không
• health check có chạy không
• endpoint quan trọng có còn trả đúng response không
• cache có còn hết hạn đúng thời gian không
• DB query chính có còn đúng không
• auth và permission có còn đúng không
• worker / cron / queue nếu có có còn chạy không

Nếu có CI thì tốt. Nếu chưa có đủ test tự động, vẫn phải có:

• manual smoke test checklist

Đưa production lên sau cùng, không phải sau khi compile xanh

Một project nâng thành công không có nghĩa là:

• npm run build xanh

Nó chỉ thật sự thành công khi:

• review diff xong
• test xong
• smoke test xong
• staging ổn
• production rollout có kiểm soát

Nâng NestJS bằng AI mà bỏ qua bước staging hoặc verification sau nâng là rất nguy hiểm.

Nên coi AI là công cụ nào trong việc này

AI rất giỏi ở các việc:

• đọc compile error
• đề xuất import mới
• đổi API cũ sang API mới
• khoanh vùng breaking change
• gợi ý package cần xem lại

Nhưng AI không nên được giao quyền:

• tự quyết định refactor kiến trúc
• tự gom service
• tự đổi flow nghiệp vụ
• tự kết luận một breaking change là “không ảnh hưởng”

Vai trò đúng là:

• AI hỗ trợ nâng version
• dev giữ quyền quyết định logic

Kết luận

Nếu muốn nâng NestJS 7 lên 11 bằng AI mà ít lỗi, hãy nhớ:

• nâng từng major version
• chỉ nâng package cần thiết
• khoanh các package có breaking change lớn như TypeORM và cache
• review mọi thay đổi bằng git
• test lại sau mỗi bước
• chỉ đưa production lên sau khi staging và verification đã ổn

AI có thể giúp bạn nâng nhanh hơn rất nhiều.

Nhưng thứ giúp bạn không làm vỡ hệ thống không phải bản thân AI.

Thứ giúp bạn an toàn là:

• phạm vi rõ
• diff rõ
• test rõ
• và kỷ luật nâng từng bước

Nguồn chính thức nên đọc thêm

• NestJS migration guide
• NestJS caching
• NestJS rate limiting
• TypeORM docs
• TypeORM find options