NestJS versiyalarini yangilash: 10 → 11 → 12, npm-check-updates va 7 kun qoidasi

Qisqacha: Nest major versiyasini yangilash — bitta buyruq emas, reja. Tartibi: (1) changelog va ko'chish qo'llanmasini o'qish, (2) alohida branch'da bitta major qadam, (3) hamma @nestjs/* paketlari bir xil versiyada, (4) npm run check (endi build bilan) va jonli tekshiruv. Nest 11 Express 5 ni (yangi yo'l sintaksisi *splat) va cache-manager 6 + Keyv'ni olib keldi; Nest 12 paketlari ESM-only va sukut test vositasi Vitest. Yangi versiyani chiqqan kunida emas, kamida 7 kundan keyin olamiz — npm-check-updates --cooldown 7 buni avtomatik qiladi.

Bu darsda

• Nest 11 va 12 dagi asosiy buzuvchi o'zgarishlarni va ular kodda qayerda ko'rinishini bilasiz.
• npm-check-updates bilan yangilanishlarni ko'rasiz va --cooldown nima uchun kerakligini tushuntirasiz.
• "7 kun qoidasi" va semver tartibini o'zingiz hisoblaysiz.
• Ko'chishda uchragan haqiqiy holatlarni (Apollo, cache-manager, olib tashlangan versiya) tanib olasiz.
• vazifalar-api 2.0.0 ni yakunlab, commit qilasiz.

Oldin bilishingiz kerak: Semver va versiya diapazonlari, Express 5 yo'l sintaksisi, CJS va ESM birga: interop va require(esm), NestJS prodakshnda, Keshlash: CacheModule.

O'tgan darsda check skriptiga build qo'shdik. Bu bugungi mavzuning poydevori: yangilashdan keyin "hammasi ishlaydimi?" degan savolga bitta buyruq javob beradi.

1. Nega bu kerak?

Kod yozilib, ishlab tursa ham, uning bog'liqliklari to'xtamaydi. Har hafta yangi versiyalar chiqadi: xavfsizlik tuzatishlari, xato tuzatishlari, yangi imkoniyatlar. Yangilamaslik ham, o'ylamasdan yangilash ham xavfli:

• Yangilamaslik: bir yildan keyin Nest 10 dagi loyiha Node'ning yangi versiyasida ishlamaydi, xavfsizlik tuzatishlari eski major'ga kelmaydi, yangi kutubxonalar talab qiladigan versiyani bera olmaysiz.
• O'ylamasdan yangilash: npm update dan keyin ilova ishga tushmaydi va qaysi paket aybdorligini topish soatlab vaqt oladi.

Nest major versiyasi taxminan yiliga bir marta chiqadi. Hozir: 12 — joriy (latest), 11 — legacy (faqat tuzatishlar), 10 — old.

O'xshatish: uyni ta'mirlash. Hammasini bir kunda buzib qayta qursangiz — qayerda nima buzilganini bilmaysiz. Xonama-xona, har xonadan keyin chiroq va suvni tekshirib borsangiz — muammo darrov ko'rinadi.

2. Nest qaysi versiyada va qanday tanlanadi

2.1 dist-tags

npm har paketga teglar beradi — "bu nom qaysi versiyaga ishora qiladi". Biz ishga tushirdik (2026-11-02):

npm view @nestjs/core dist-tags

{
  rc: '6.0.0-rc.1',
  beta: '9.3.0-beta.3',
  old: '10.4.19',
  next: '12.0.0-alpha.7',
  legacy: '11.2.8',
  latest: '12.3.2'
}

npm i @nestjs/core — latest ni oladi. legacy — Nest 11 ning so'nggi versiyasi, hali tuzatishlar oladi. rc, beta, next — eski sinov versiyalari, ularni o'rnatmang (Semver va versiya diapazonlari).

2.2 Chiqish sanalari

npm view @nestjs/core time --json

Kerakli qismi (oxirgi 14 versiya):

11.2.5 2026-09-15
12.0.3 2026-09-15
12.0.4 2026-09-21
12.1.0 2026-09-23
11.2.6 2026-09-23
12.1.1 2026-09-28
12.1.2 2026-09-30
11.2.7 2026-09-30
12.1.3 2026-10-12
12.2.0 2026-10-19
11.2.8 2026-10-23
12.3.0 2026-10-27
12.3.1 2026-10-27
12.3.2 2026-10-27

Ikki narsaga qarang:

1. Ikki major parallel yashaydi. 11.2.8 (2026-10-23) 12.2.0 (2026-10-19) dan keyin chiqqan. Sana bo'yicha saralasangiz, "eng yangisi" 11.2.8 bo'lib qoladi — bu xato. Versiyalar semver bo'yicha saralanadi.
2. Bir kunda uchta versiya: 12.3.0, 12.3.1, 12.3.2 — 2026-10-27. Bu odatda birinchi relizda xato topilib, darrov tuzatilganini bildiradi. Shuning uchun yangi relizni chiqqan kuni olmaymiz.

2.3 7 kun qoidasi

Kanon qoidasi: har paketdan 7 kundan eski eng yangi barqaror versiya. Sabablari:

• yangi relizdagi xato odatda bir necha kunda topiladi va tuzatiladi;
• npm'ga zararli versiya (supply chain hujumi) tushsa, uni odatda bir necha soat yoki kunda olib tashlashadi.

Kanon 2026-10-27 da Nest 12.3.x ni ko'rdi, lekin 12.2.0 ni oldi — shuning uchun butun qism NestJS 12.2.0 da. Qoidani kichik modelda hisoblaymiz (brauzerda ishlaydi):

const BUGUN = Date.parse("2026-11-02");
const KUN = 24 * 60 * 60 * 1000;
const time = {
  "12.2.0": "2026-10-19", "11.2.8": "2026-10-23",
  "12.3.0": "2026-10-27", "12.3.2": "2026-10-27",
  "12.4.0-rc.1": "2026-10-30", "11.2.7": "2026-09-30",
};

const sv = (v) => v.split(".").map(Number);
const semverKamayish = ([a], [b]) => {
  const [x, y] = [sv(a), sv(b)];
  return y[0] - x[0] || y[1] - x[1] || y[2] - x[2];
};

function tanla(time, kun) {
  const barqaror = Object.entries(time)
    .filter(([v]) => /^\d+\.\d+\.\d+$/.test(v))
    .sort(semverKamayish);
  const chegara = BUGUN - kun * KUN;
  return {
    engYangi: barqaror[0][0],
    tanlov: barqaror.find(([, s]) => Date.parse(s) <= chegara)?.[0],
  };
}

console.log("0 kun:", tanla(time, 0));
console.log("7 kun:", tanla(time, 7));
const sanaBoyicha = Object.entries(time)
  .filter(([v]) => /^\d+\.\d+\.\d+$/.test(v))
  .filter(([, s]) => Date.parse(s) <= BUGUN - 7 * KUN)
  .sort(([, a], [, b]) => b.localeCompare(a))[0][0];
console.log("sana bo'yicha (xato):", sanaBoyicha);

Konsolda:

0 kun: { engYangi: '12.3.2', tanlov: '12.3.2' }
7 kun: { engYangi: '12.3.2', tanlov: '12.2.0' }
sana bo'yicha (xato): 11.2.8

Uchinchi qator — saboq: sana bo'yicha tanlasak, 12-major loyihaga 11.2.8 tavsiya qilinardi. 12.4.0-rc.1 esa regex'dan o'tmadi — sinov versiyasi. Kanon skripti (skriptlar/versiya.mjs) xuddi shu mantiqni npm view … time va versions bilan bajaradi. versions nega kerak — «Ko'chishda uchragan haqiqiy holatlar» bo'limida.

Tekshirib ko'ring: Bugun 2026-11-02. Yuqoridagi ro'yxatga qarab: qaysi kuni 7 kun qoidasi 12.3.2 ni tanlay boshlaydi?

3. npm-check-updates

3.1 Nima qiladi

npm outdated yangilanishlarni ko'rsatadi, lekin package.json ga yozmaydi. npm-check-updates (ncu) — package.json dagi har bog'liqlikni eng yangi versiya bilan solishtiradi, jadval chiqaradi, -u bilan esa faylni yangilaydi. U o'zi hech narsa o'rnatmaydi — keyin npm install qilasiz.

Kanon ncu'ni ishlatmagan. Biz vazifalar-api nusxasida sinab ko'rdik (npm-check-updates 23.1.1, 2026-11-02). --cooldown 7 — 7 kundan yangi versiyalarni hisobga olmaslik:

npx npm-check-updates@23.1.1 --cooldown 7

Patch   Backwards-compatible bug fixes
 @nestjs/cli         12.0.9  →  12.0.10  [cooldown] 12.0.11
 @nestjs/schematics  12.0.9  →  12.0.10  [cooldown] 12.0.12
 @nestjs/swagger     12.0.2  →   12.0.4  [cooldown] 12.0.5
 vite                 8.3.4  →    8.3.5

Minor   Backwards-compatible features
 typescript-eslint  8.71.2  →  8.72.0  [cooldown] 8.72.1

Major   Potentially breaking API changes
 @types/node  24.19.2  →  26.6.5  [cooldown] 26.6.6
 typescript     6.0.3  →   7.0.2

Run npx npm-check-updates --cooldown 7 -u to upgrade package.json

Jadval uch guruhga bo'lingan — semver bo'yicha xavf darajasi:

• Patch — xato tuzatishlari. Odatda xavfsiz.
• Minor — yangi imkoniyatlar, eskisi buzilmaydi (va'da bo'yicha).
• Major — buzuvchi o'zgarishlar mumkin. Alohida, o'ylab.

[cooldown] 12.0.11 — "undan yangisi bor, lekin 7 kun o'tmagan". @nestjs/core jadvalda yo'q: 12.3.x hali 7 kunlik emas, 12.2.0 esa allaqachon o'rnatilgan.

3.2 Cooldown'siz

Taqqoslash uchun — --target minor (major'larsiz, lekin cooldown'siz):

npx npm-check-updates@23.1.1 --target minor

 @nestjs/cli         12.0.9  →  12.0.11
 @nestjs/schematics  12.0.9  →  12.0.12
 @nestjs/swagger     12.0.2  →   12.0.5
 nestjs-cls           7.0.1  →    7.0.2
 redis                6.3.0  →    6.3.1
 vite                 8.3.4  →    8.3.5
 @nestjs/common             12.2.0  →   12.3.2
 @nestjs/core               12.2.0  →   12.3.2
 @nestjs/platform-express   12.2.0  →   12.3.2
 @nestjs/testing            12.2.0  →   12.3.2
 eslint                    10.13.0  →  10.14.0
 typescript-eslint          8.71.2  →   8.72.1

Jadvallar orasidagi farq — cooldown "ushlab qolgan" yangi relizlar. Sarlavha qatorlari qisqartirildi.

Diqqat: Hamma @nestjs/* yadro paketlari (common, core, platform-*, testing) bir xil versiyada bo'lsin. @nestjs/core 12.3.2 va @nestjs/common 12.2.0 aralashmasi g'alati DI xatolarini beradi. Ekotizim paketlari (@nestjs/config, @nestjs/swagger, @nestjs/schedule) — o'z versiyalari bilan, faqat bir xil major.

4. Nest 11 va 12 dagi buzuvchi o'zgarishlar

4.1 Nest 10 → 11

Express 5 yo'l sintaksisi — eng ko'p uchraydigan muammo. 25-qismda o'rgandik (Express 5 yo'l sintaksisi): yalang'och * endi xato, joker nomlanishi shart. Nest'da bu forRoutes va dekorator yo'llariga ham tegadi. vazifalar-api ning app.module.ts dan:

// ("*splat" — Express 5 / path-to-regexp 8 sintaksisi; eskirgan()
// o'zi /vazifalar, /teglar prefiksini tekshiradi)
consumer.apply(eskirgan(ESKI_YOLLAR)).forRoutes("*splat");

Nest 10 da bu forRoutes("*") edi. Eski sintaksis Nest 12 da nima qiladi — demo ilovada sinadik (biz ishga tushirdik, NestJS 12.2.0): middleware forRoutes("*") bilan, marshrut esa @Get("f/*") bilan. Ikkalasi ham ishladi, lekin ishga tushishda bitta ogohlantirish chiqdi:

WARN [LegacyRouteConverter] Unsupported route path: "/v/f/*". In previous versions, the symbols ?, *, and + were used to denote optional or repeating path parameters. The latest version of "path-to-regexp" now requires the use of named parameters. For example, instead of using a route like /users/* to capture all routes starting with "/users", you should use /users/{*path}. The braces keep the wildcard optional, so it covers the same paths as /users/* did, while /users/*path is narrower and requires at least one extra segment. For more details, refer to the migration guide. Attempting to auto-convert to "/v/f/{*path}"...

Tarjimasi: "Qo'llab-quvvatlanmaydigan yo'l: /v/f/*. Oldingi versiyalarda ?, * va + belgilari ixtiyoriy yoki takrorlanuvchi parametrni bildirardi. path-to-regexp'ning yangi versiyasi nomlangan parametr talab qiladi: /users/* o'rniga /users/{*path}. Qavslar jokerni ixtiyoriy qiladi — eski /users/* bilan bir xil yo'llar; /users/*path torroq — kamida bitta qo'shimcha segment kerak. Avtomatik /v/f/{*path} ga aylantirishga urinilmoqda…"

Nest yalang'och * ni o'zi aylantirdi va so'rov 200 oldi. forRoutes("*") esa ogohlantirishsiz ishladi — u alohida holat sifatida qayta ishlanadi. Ogohlantirishni e'tiborsiz qoldirmang: "avtomatik aylantirish" — vaqtinchalik ko'prik, xabar o'zi to'g'ri shaklni aytib turibdi.

cache-manager va Keyv — Keshlash: CacheModule darsida ko'rdik: Redis store endi new KeyvRedis(...) bilan beriladi va kalitlar prefikssiz saqlanadi. Eski redisStore misollari internetda ko'p — ular Nest 11 da ishlamaydi.

4.2 Nest 11 → 12

ESM-only — Nest 12 paketlari faqat ES modul sifatida chiqadi. vazifalar-api boshidan ESM ("type": "module"), bu o'zgarish unga tegmadi. Eski CommonJS Nest loyihasi esa Node'ning require(esm) imkoniyatiga tayanadi — Node 20.19 va 22.12 dan boshlab sukut bo'yicha yoqilgan (CJS va ESM birga). Eski Node'da — ERR_REQUIRE_ESM.

Node talablari jadvali Nest'ning rasmiy ko'chish qo'llanmasidan (2026-11 holatiga): ilovani ishga tushirish uchun Node 20.19+ yetadi, lekin CLI generatorlari yangiroq Node so'raydi. Kanon Node 24.21 da ishladi — ikkalasiga ham mos.

Kanon to'g'ridan Nest 12 da yozildi — 11 → 12 ko'chishini sinamadi. Jadvallar Nest'ning ko'chish qo'llanmalari va kanon ishida uchragan holatlarga asoslangan.

5. Ko'chishda uchragan haqiqiy holatlar

Bu qismdagi kanon ishida versiyalar bilan bog'liq to'rtta haqiqiy holat uchradi:

1. Apollo + Express 5. GraphQL tajribasida (Nest 12, Apollo 5) @as-integrations/express5 peer paketi kerak bo'ldi. U yo'q va logger: false bo'lsa — jarayon hech qanday xabarsiz exit 1 bilan tugadi (GraphQL code-first). Saboq: ko'chishdan keyingi birinchi sinovda loglarni o'chirmang.
2. cache-manager 7 + Keyv. Store stores: [new KeyvRedis()] bilan beriladi, kalit Redis'da prefikssiz yoziladi — boshqa ilova bilan bitta Redis'ni bo'lishsa, to'qnashuv mumkin.
3. Olib tashlangan versiya. npm view cache-manager time da 7.2.10 bor edi, lekin o'rnatib bo'lmadi — u npm'dan olib tashlangan (unpublished). time olib tashlangan versiyalarni ham saqlaydi. Shuning uchun kanon skripti npm view … versions bilan solishtiradi: faqat haqiqatan mavjud versiyalar.
4. Vite va tsc farqi. Aylanma import Vitest'da o'tadi, build'dan keyin esa ilova TDZ bilan yiqiladi (Circular dependency). Yangilashdan keyin "testlar yashil" yetmaydi — check dagi build shu uchun.

nest upgrade (Nest CLI'ning yangilash buyrug'i) — kanon ham, biz ham sinamadik.

6. Yangilash tartibi

flowchart TB
  A["Changelog va ko'chish qo'llanmasi"] --> B["Yangi branch"]
  B --> C["Patch va minor: ncu --cooldown 7 -u"]
  C --> D["npm install + npm run check"]
  D --> E{"Yashilmi?"}
  E -- ha --> F["Commit, keyin bitta major"]
  E -- yo'q --> G["Paketlarni birma-bir qaytarib, aybdorni toping"]
  F --> H["Major: o'qish → o'zgartirish → check → jonli tekshiruv"]
  G --> D

Diagrammadagi asosiy g'oya: kichik qadamlar va har qadamdan keyin tekshiruv. Patch va minor'lar bitta commit. Har major — alohida commit. Bir vaqtda Nest 10 → 12 va TypeScript 5 → 7 qilinsa, xato kimdan ekanini topib bo'lmaydi.

npm run check (tip + lint + test + build) — avtomatik qism. Jonli tekshiruv — qo'lda: ilovani ishga tushirib, asosiy so'rovlarni yuborish. Kanon har holatda 9 ta curl so'rovini uch rejimda (Postgres, Prisma, Prisma + Redis kesh) yuborgan.

Tekshirib ko'ring: ncu Major guruhida typescript 6.0.3 → 7.0.2 ni ko'rsatdi. Nest loyihasida uni darrov yangilash kerakmi?

7. Ko'p uchraydigan xatolar

8. Mashqlar

Mashqlar kurs/mashqlar/30/54-yangilash/ da.

1-mashq (oson): xavf darajasi

Semver bo'yicha har yangilanish qaysi guruhga kiradi: patch, minor yoki major?

• @nestjs/swagger 12.0.2 → 12.0.4 —
• typescript-eslint 8.71.2 → 8.72.0 —
• @types/node 24.19.2 → 26.6.5 —
• Nest 11 dagi forRoutes("*") → forRoutes("*splat") qaysi paketning major yangilanishidan?

2-mashq (o'rta): semver taqqoslash

semverTaqqosla(a, b) funksiyasini yozing: a > b bo'lsa musbat, teng bo'lsa 0, kichik bo'lsa manfiy son. Faqat X.Y.Z shakli. Keyin ["11.2.8", "12.2.0", "12.10.0", "12.3.2", "9.4.3"] ni kamayish tartibida saralang. Ishora: satr sifatida taqqoslash ("12.10.0" < "12.3.2") xato beradi — sonlarga ajrating (sort va taqqoslash funksiyasi).

function semverTaqqosla(a, b) {
  const [x, y] = [a, b].map((v) => v.split(".").map(Number));
  for (let i = 0; i < 3; i++) {
    if (x[i] !== y[i]) return x[i] - y[i];
  }
  return 0;
}

const versiyalar = ["11.2.8", "12.2.0", "12.10.0", "12.3.2", "9.4.3"];
console.log(versiyalar.toSorted((a, b) => semverTaqqosla(b, a)));
console.log("satr bo'yicha (xato):",
  versiyalar.toSorted().toReversed());

[ '12.10.0', '12.3.2', '12.2.0', '11.2.8', '9.4.3' ]
satr bo'yicha (xato): [ '9.4.3', '12.3.2', '12.2.0', '12.10.0', '11.2.8' ]

3-mashq (qiyin): yangilash rejasi

reja(paketlar) funksiyasini yozing. Kirish — { nom, joriy, yangi } obyektlar massivi. Natija: patch va minor yangilanishlar bitta "1-qadam" ro'yxatida, har major esa alohida qadamda (alfavit tartibida). Har qadamni "1-qadam: a, b" shaklida chiqaring. Ishora: avval semver darajasini aniqlovchi daraja(joriy, yangi) yozing.

function daraja(joriy, yangi) {
  const [a, b] = [joriy, yangi].map((v) => v.split(".").map(Number));
  if (a[0] !== b[0]) return "major";
  if (a[1] !== b[1]) return "minor";
  return "patch";
}

function reja(paketlar) {
  const xavfsiz = [];
  const majorlar = [];
  for (const p of paketlar) {
    const d = daraja(p.joriy, p.yangi);
    (d === "major" ? majorlar : xavfsiz).push(p.nom);
  }
  const qadamlar = [];
  if (xavfsiz.length > 0) qadamlar.push(xavfsiz);
  for (const m of majorlar.toSorted()) qadamlar.push([m]);
  return qadamlar;
}

const paketlar = [
  { nom: "@nestjs/swagger", joriy: "12.0.2", yangi: "12.0.4" },
  { nom: "typescript", joriy: "6.0.3", yangi: "7.0.2" },
  { nom: "typescript-eslint", joriy: "8.71.2", yangi: "8.72.0" },
  { nom: "@types/node", joriy: "24.19.2", yangi: "26.6.5" },
  { nom: "vite", joriy: "8.3.4", yangi: "8.3.5" },
];
reja(paketlar).forEach((q, i) => {
  console.log(`${i + 1}-qadam: ${q.join(", ")}`);
});

1-qadam: @nestjs/swagger, typescript-eslint, vite
2-qadam: @types/node
3-qadam: typescript

9. Loyiha qadami: vazifalar-api 2.0.0

Bu — 2.0.0 qadamining oxirgi qismi. Avvalgi ikki darsda buyruq.ts, check va test:qamrov qo'shildi. Endi tozalash, versiya va hujjatlar.

9.1 Ishlatilmay qolgan kodni olib tashlash

src/umumiy/tekshir.ts da 25-qismdan qolgan tekshirib() funksiyasi bor — Express marshrutlari uchun validatsiya middleware'i. Nest'da kirishni SxemaPipe tekshiradi (Zod va Standard Schema NestJS'da), tekshirib() hech qayerda chaqirilmaydi. Olib tashlanadi; tekshir() — bitta qiymatni tekshiradigan funksiya — qoladi. Fayl boshidagi izoh va importlar:

 // tekshir.ts — chegarada tekshiruv (trust boundary): tashqaridan
 // kelgan har qiymat Zod sxemasidan o'tadi.
-// tekshir() — bitta qiymat (typed natija); tekshirib() — qayta
-// ishlatiladigan middleware: body/query/params bir joyda
+// tekshir() — bitta qiymat (typed natija). 30-qism: HTTP kirishi —
+// SxemaPipe (Nest @Body/@Query/@Param({ schema })); Express
+// middleware'i tekshirib() olib tashlandi
 import { z } from "zod";
-import type { Request, RequestHandler, Response } from "express";
 import { ParametrXatosi, ValidatsiyaXatosi } from "./xatolar.ts";

Fayl oxiridagi type Sxemalar, type Chiqish va export function tekshirib(...) (20 qator) to'liq o'chiriladi. Izoh qatorlari telefon uchun bo'lingan.

Nega bu muhim? Ishlatilmaydigan kod ham o'qiladi, yangilanadi va qamrov foizini pasaytiradi. Express import qiladigan fayl kamaydi — keyinroq adapter almashtirilsa, bir joy kam (Fastify adapter bilan NestJS).

9.2 Versiya va hujjatlar

package.json:

-  "version": "2.0.0-alfa.0",
+  "version": "2.0.0",

Major versiya — 2. HTTP shartnomasi o'zgarmagan bo'lsa ham, ichki tuzilma butunlay boshqa: Node versiyasi talabi, build qadami, ishga tushirish buyrug'i (npm start → dist/main.js). Deploy qiluvchi uchun bu buzuvchi o'zgarish.

Hujjatlar:

• README.md — NestJS 12 (Express 5 adapteri), build bor (nest build → dist/), .ts importlar va SWC ishlamasligi, npm run buyruq, yangi papka xaritasi (src/ilova.ts, src/app.module.ts, src/ombor.module.ts …).
• API.md — yangi yo'llar (/v1/vazifalar/oqim SSE, /health/live|ready, /docs) va o'zgarishlar jurnali: "v2.0.0 (30-qism): server NestJS 12 da (HTTP shartnomasi o'zgarmadi — 25–27 testlari o'tadi)" va /toplam tuzatishi.
• TESTLAR.md — Vitest, test darajalari jadvali ("Unit (Nest DI) — birlik"), qamrov chegaralari va jarayon.ts qamrovga tushmasligi, "CI'da npm run build ham shart".
• .env.example — birinchi qator izohi (Node .env ni o'zi o'qiydi — --env-file-if-exists; Nest ConfigModule ignoreEnvFile: true) va lokal Postgres porti.

Hujjatlarni o'zgarishlar bilan bitta commit'da yangilash — README eskirmaydi.

9.3 Yakuniy tekshiruv

npm run check
npm run test:qamrov
npm run build && npm start

Kanon yakuniy tekshiruvi (bazali testlar bilan, Docker'dagi Postgres 18.6). Har buyruqdan keyin exit 0 borligini va eng oxirgi — Testcontainers qatoridagi Tests natijasini toping:

--- npm run tip
exit 0 (8531 ms)
--- npm run lint
exit 0 (19855 ms)
--- npm run test
 ↓ test/konteyner.test.ts (1 test | 1 skipped)
 Test Files  25 passed | 1 skipped (26)
      Tests  130 passed | 1 skipped (131)
exit 0 (20572 ms)
--- npm run build
exit 0 (10136 ms)
--- Testcontainers (TESTCONTAINERS=1):  [Testcontainers vaqtlari] konteyner 2366 ms, migratsiya 30678 ms  Tests 10 skipped (10) ; kanon30-tc qoldiqlari: 0

Tip, lint, 130 test va build — yashil. Jonli tekshiruv: 9 so'rov uch rejimda (Postgres, Prisma, Prisma + kesh) — 27 javob, hammasi kutilgan statuslar bilan (200, 201, 204, 404, 409, 412).

Testcontainers qatoriga e'tibor bering: 10 skipped. Migratsiya 30.7 s oldi — beforeAll hook'ining chegarasi (30 s, hookTimeout) o'tib ketdi va konteyner testlari bajarilmadi. O'tgan qadamda xuddi shu testlar 10/10 o'tgandi, migratsiya 1.9 s edi. Kod o'zgarmagan — mashina boshqa ishlar bilan qattiq band edi. Halol xulosa: yakuniy holatda Testcontainers to'plami tasdiqlanmagan, oldingi qadamdagi natijaga tayanamiz. O'zingizda TESTCONTAINERS=1 npm test ni yurgizing va 10/10 ni ko'ring; yuklangan CI mashinasi uchun hookTimeout ni oshirish kerak bo'lishi mumkin.

9.4 Commit

git add -A
M="feat: vazifalar-api 2.0.0 — NestJS 12; standalone buyruq"
M+=" (npm run buyruq), Vitest qamrovi, README/API/TESTLAR yangilandi"
git commit -m "$M"

git add -A dan oldin git status ga qarang: dist/, coverage/ va .env kirmasin (.gitignore). Commit Nest CLI va loyiha tuzilmasi darsida ochilgan nest tarmog'iga tushadi; main esa 29-qism holatidagi Express API bo'lib qoladi.

Shu bilan vazifalar-api ning auth'siz qismi Nest'ga to'liq ko'chdi: 25–27-qismlardagi butun v1 API, testlar, buyruq va hujjatlar. Keyingi darslarda 28-qismdagi auth shu loyihaga ko'chadi.

10. Real ishda

• Dependabot va Renovate — GitHub'da yangilanish PR'larini avtomatik ochadigan botlar. Renovate'da minimumReleaseAge: "7 days" — xuddi shu 7 kun qoidasi. Har PR'da CI npm run check ni yurgizadi.
• Major yangilash — loyiha ishi. Katta jamoalarda Nest major'i uchun alohida vazifa ochiladi: changelog o'qiladi, ogohlantirishlar tuzatiladi, staging'da sinaladi.
• Lock fayl — package-lock.json har doim commit qilinadi: serverda aynan sinalgan versiyalar o'rnatiladi (npm ci).
• Intervyu: "Nest'ni 10 dan 11 ga qanday yangilaysiz?", "Nega yangi relizni darhol olmaysiz?", "^ va ~ farqi?", "Lock fayl nima uchun?".

Xulosa

• Yangilash — reja: changelog, alohida branch, patch/minor bitta qadam, har major alohida, har qadamdan keyin npm run check.
• Hamma @nestjs/* yadro paketlari bir xil versiyada; versiyalar semver bo'yicha saralanadi, sana bo'yicha emas.
• 7 kun qoidasi: ncu --cooldown 7 yoki kanon skripti; olib tashlangan versiyani versions bilan tekshirish.
• Nest 11: Express 5 (*splat), cache-manager + Keyv, Node 20+; Nest 12: ESM-only, Vitest, Standard Schema.
• vazifalar-api 2.0.0: tekshirib() olib tashlandi, hujjatlar yangilandi; yakuniy Testcontainers yuk tufayli SKIP — halol aytildi.

Keyingi dars: Passport NestJS'da — auth'ni oxirga qoldirgan edik; endi butun loyiha Nest'da va 28-qismdagi auth unga ko'chadi.

Manbalar

• NestJS hujjati — Migration guide (v11 va v12; Node talablari, Jest uchun Node 24.9+, 2026-11-02 da o'qildi): https://docs.nestjs.com/migration-guide
• npm-check-updates — README (--cooldown, --target): https://github.com/raineorshine/npm-check-updates
• Renovate — minimumReleaseAge: https://docs.renovatebot.com/configuration-options/#minimumreleaseage
• Kanon (IlmHamroh, 2026-10-28): skriptlar/versiya.mjs, loyihaning yakuniy tekshiruvi, ko'chishda uchragan holatlar. dist-tags, time, versiya.mjs va npm-check-updates chiqishlari — biz ishga tushirdik (2026-11-02, npm 11.19.0, npm-check-updates 23.1.1).