Vite+ 1.1.0 ile araç zincirini sadeleştirmek: JSON-LD aracından test ve CI'a

Vite+ neyi birleştiriyor?

Başlangıç noktası küçük bir iş: bir JSON-LD nesnesini denetleyen tarayıcı aracı. Böyle bir araç büyüdükçe Vite, TypeScript, ESLint, Prettier ve Vitest ayrı bağımlılıklar ve ayrı yapılandırma dosyalarıyla yan yana yaşar. Bu yazı o dağınıklığı Vite+ ile nasıl toplayabileceğinizi tek bir uygulamayla gösteriyor: yeni proje, mevcut projenin göçü, testler ve CI.

Vite+ 1.0.0, 28 Eylül 2026'da yayımlandı ve bu yazının çıkış noktası o lansman. Ancak uygulamalı adımlarda kayda alınan Vite+ komutlarını 1.1.0 ile denedim: 10 Ekim 2026'da kontrol ettiğimde GitHub'ın son sürümü, 7 Ekim 2026'da yayımlanan 1.1.0'dı ve npm'deki latest etiketi de onu gösteriyordu. Yani 1.0.0 dönüm noktasıdır, güncel sürüm değil; göç sonrası sürümler, çıktılar ve yapılandırmalar 1.1.0'a aittir.

Vite+ nedir? Mevcut araçların üstünde duran birleşik bir komut satırı (vp) ve ortak bir yapılandırma katmanı. “Birleştirmek” hepsinin tek bir çalıştırılabilir dosyaya derlendiği anlamına gelmez: Vite, Rolldown, Vitest, Oxlint, Oxfmt, tsdown ve Vite Task entegre araç zinciri tarafından sağlanır. Düz Vite geliştirme sunucusu ve üretim derlemesi sunar (üretim paketleyicisi Rolldown'dur); Vite+ aynı iş akışına lint, biçimlendirme, test ve görev çalıştırmayı ekler. Vite+ MIT lisanslıdır; ilk duyurudaki ticari lisans planı artık geçerli değil. Mevcut Vite eklentilerinizi ve framework varsayımlarınızı kendi projenizde ayrıca doğrulamanız gerekir.

Sayfanın başındaki şema, örnek projedeki ayrı yapılandırma yüzeyini (eslint.config.js, .prettierrc.json, vite.config.ts) ortak giriş noktasıyla karşılaştırıyor. Şema niteliksel bir çizimdir, ölçüm değildir. Her yapılandırma dosyasının ortadan kalktığı anlamına da gelmez: paket bildirimi, kilit dosyası ve tsconfig.json yerinde kalır.

Yazı iki yolu ayrı tutar. Yeni proje başlatıyorsanız fresh-demo yolunu izleyin (3. bölüm). Mevcut bir projeniz varsa jsonld-demo yolunu izleyin: klasik kurulumu doğrularız (5. bölüm), sonra vp migrate ile taşırız (6. bölüm). Yeni projeyi göçü öğrenmek için geri almanız gerekmez; iki yol bağımsızdır ve aynı küçük uygulamayı taşır.

Sürümü ve ortamı sabitleyin

Vite+ iki biçimde bulunur. Proje içinde vite-plus bağımlılığı olarak kurulan yerel CLI, sürümü projeyle birlikte sabitler ve var olan bir Node çalışma zamanına dayanır. İsteğe bağlı küresel vp ise çalışma zamanlarını ve paket yöneticilerini de yönetebilir. Kurulum komutları için Vite+ başlangıç sayfasına bakın: bir kabuk betiği ve bir Windows PowerShell yükleyicisi belgeleniyor. Ben bu betikleri çalıştırmadım: resmî Linux arşivini indirdim, SHA-256 özetini yayımlanan özetle karşılaştırdım ve bütün Vite+ dizinlerini geçici bir klasöre yönlendirerek çalıştırdım. Bu arşivin denemesidir, yükleyici betiklerinin değil; imza ya da atestasyon doğrulaması da yapmadım.

Node gereksinimi tam olarak ^22.18.0 || ^24.11.0 || >=26.0.0 aralığıdır; bunu “Node 20+” ya da yalnızca “Node 22+” diye kısaltmayın. Örnek proje Node 24.11.0 ve npm 11.6.1 ile denendi ve bunu iki yerde sabitledim: .node-version dosyasında 24.11.0, package.json'daki packageManager alanında [email protected]. Paket yöneticinizin kendi alt sınırı da olabilir (3. bölümde gerçek bir örnek var): en güncel npm'i desteklenen en eski Node ile körlemesine eşleştirmeyin.

Etkin sürümleri vp --version söyler; vp toolchain ayrıntıyı verir ve --global bayrağıyla küresel kurulumu gösterir. Örnek projedeki kayıt şöyleydi:

01$ vp --version02vp v1.1.003 04Local vite-plus:05  vite-plus  v1.1.006 07Tools:08  vite             v8.3.309  rolldown         v1.2.1210  vitest           v5.0.311  oxfmt            v0.72.012  oxlint           v1.87.013  oxlint-tsgolint  v7.0.200314  tsdown           v0.23.015 16Environment:17  Package manager  npm v11.6.118  Node.js          v24.11.0 (.node-version)

Önemli bir ayrım: Vite+ 1.1.0'ın içindeki Vite, Rolldown ve Vitest, ayrı yayımlanan en son sürümlerle aynı olmak zorunda değil. Tablo 10 Ekim 2026'daki durumu gösteriyor.

Kilit dosyası da sabitlemenin parçası. vp install projenin seçtiği paket yöneticisini kullanır, onun yerine geçmez; burada npm package-lock.json üretir. Gerçek projede onu depoya ekleyin ki CI aynı bağımlılık ağacını kursun; 8. bölümdeki iş akışları bu yüzden vp install --frozen-lockfile ile başlar.

Yeni proje ve küçük arayüz

Yeni proje yolu vp create ile başlar. vite kısayoluyla şablon Vite'ın kendi oluşturucusuna devredilir ve proje klasörünün adı -- işaretinden sonra verilir. İlk denememde --directory jsonld-demo biçimini kullandım ve komut 1 koduyla çıktı: The --directory option is only available for builtin and bundled @org templates. Bu yüzden öğreticide yalnızca başarılı olan biçimi kullanıyoruz.

Komutu, etkileşimi ve agent, editor, hooks, git seçeneklerini kapatan bayraklarla, npm'i seçerek ve mevcut projenin üzerinde değil, ayrı bir kardeş klasörde çalıştırdım. Çıktı:

01$ vp create vite --package-manager npm --no-interactive --no-agent --no-editor --no-hooks --no-git -- fresh-demo --template vanilla-ts --no-interactive02●  npm@latest installing...03●  [email protected] installed04◇  Generating project…05●  Running: npx create-vite fresh-demo --template vanilla-ts --no-interactive 06   --no-immediate --no-rolldown07npm warn cli npm v12.2.0 does not support Node.js v24.11.0. This version of npm supports the following node versions: `^22.22.2 || ^24.15.0 || >=26.0.0`. You can find the latest version at https://nodejs.org/.08npm warn exec The following package was not found and will be installed: [email protected]09npm notice run npx10npm notice run 'create-vite' fresh-demo --template vanilla-ts --no-interactive --no-immediate --no-rolldown11│12◇  Scaffolding project in /tmp/viteplus-research-oyosbm_d/fresh-demo...13│14└  Done. Now run:15 16  cd fresh-demo17  npm install18  npm run dev19 20◆  ✔ Created vite.config.ts in fresh-demo/vite.config.ts21●  Installing dependencies...22●  Dependencies installed23●  Formatting code...24●  Code formatted25◇ Scaffolded fresh-demo with Vanilla + TypeScript26• Node 24.11.0  npm 12.2.027✓ Dependencies installed in 13s28→ Next: cd fresh-demo && vp run

Çıktıdaki uyarıyı atlamayın. Betik npm@latest'i kurdu, yani npm 12.2.0'ı seçti ve bu sürümün Node 24.11.0'ı desteklemediğini bildirdi: kendi gereksinimi ^22.22.2 || ^24.15.0 || >=26.0.0. Komut yine de 0 koduyla bitti. Ben bunu şöyle düzelttim: şablonun demo dosyalarını bu yazıdaki uygulamayla değiştirdim, package.json'a packageManager: [email protected], .node-version dosyasına 24.11.0 yazdım, üretilen demo kaynaklarını ve görselleri sildim, bağımlılıkları yeniden kurdum. Hiçbiri otomatik olmadı; hepsini elle ve bilerek yaptım, düzeltmeden sonra create komutunu da yinelemedim. Alternatif, hem Vite+'ın hem npm sürümünüzün gereksinimini karşılayan daha yeni bir Node seçmektir.

Düzeltmeden sonra fresh-demo ile jsonld-demo aynı dosya kümesini taşıdı; yalnızca paket adı farklıydı. Aşağıdaki ağaç jsonld-demo'nun göç sonrası hâlidir. node_modules/ ve dist/ üretilen klasörlerdir ve depoya eklenmez.

01jsonld-demo/02├── .gitignore03├── .node-version          # 24.11.004├── index.html             # labelled form and live text result05├── package.json           # toolchain pin, scripts, core alias06├── package-lock.json      # generated; retain and commit in a real project07├── tsconfig.json          # TypeScript source selection and strict options08├── vite.config.ts         # lint + fmt + test09└── src/10    ├── main.ts            # UI event wiring11    ├── validate.ts        # pure local-policy validator12    └── validate.test.ts   # 17 cases

tsconfig.json yalnızca src klasörünü kapsar, strict kipini açar ve çıktı üretmez (noEmit); 6. bölümdeki göç onu değiştirmedi.

01{02  "compilerOptions": {03    "target": "ES2022",04    "module": "ESNext",05    "lib": ["ES2022", "DOM", "DOM.Iterable"],06    "moduleResolution": "Bundler",07    "noEmit": true,08    "strict": true,09    "skipLibCheck": true,10    "types": ["vite/client"]11  },12  "include": ["src"]13}

Arayüz bilerek küçük: index.html, bir label ile bağlanmış metin alanı, bir düğme ve sonucu duyuran bir pre içerir; role="status" ve aria-live="polite" sonucun metin olarak bildirilmesi için işaretlenmiştir.

01<!doctype html>02<html lang="en">03  <head>04    <meta charset="UTF-8" />05    <meta name="viewport" content="width=device-width, initial-scale=1.0" />06    <title>JSON-LD local checks</title>07  </head>08  <body>09    <main>10      <h1>JSON-LD local checks</h1>11      <p>This demo checks a small Article policy, not rich-result eligibility.</p>12      <form id="validator">13        <label for="source">JSON-LD source</label><br />14        <textarea id="source" rows="9" cols="60" spellcheck="false">15{"@context":"https://schema.org","@type":"Article","headline":"Hello"}</textarea16        ><br />17        <button type="submit">Check local fields</button>18      </form>19      <pre id="result" role="status" aria-live="polite"></pre>20    </main>21    <script type="module" src="/src/main.ts"></script>22  </body>23</html>

01import { validateJsonLd } from "./validate";02 03const form = document.querySelector<HTMLFormElement>("#validator");04const source = document.querySelector<HTMLTextAreaElement>("#source");05const result = document.querySelector<HTMLPreElement>("#result");06 07if (!form || !source || !result) {08  throw new Error("Missing validator UI elements.");09}10 11form.addEventListener("submit", (event) => {12  event.preventDefault();13  result.textContent = JSON.stringify(validateJsonLd(source.value), null, 2);14});

main.ts üç öğeyi bulur, biri yoksa hata fırlatır; form gönderilince varsayılan davranışı engeller ve sonucu textContent ile yazar. Kullanıcının yazdığı metin hiçbir zaman HTML olarak ayrıştırılmaz; bu davranışı koruyun. Sınır açık: çekirdek birim testleriyle doğrulandı ve arayüz başarıyla derlendi, ama tarayıcıda etkileşim ya da erişilebilirlik testi çalıştırmadım.

JSON-LD çekirdeğinin sınırı

Arayüzün çağırdığı çekirdek src/validate.ts içinde: DOM'u, ağı ya da dosyayı bilmeyen saf bir işlev; bir metin alır, üç alanlı bir sonuç döndürür.

01export type ValidationResult = {02  jsonValid: boolean;03  localValid: boolean;04  issues: string[];05};06 07export function validateJsonLd(source: string): ValidationResult {08  let value: unknown;09  try {10    value = JSON.parse(source);11  } catch {12    return { jsonValid: false, localValid: false, issues: ["Invalid JSON."] };13  }14 15  if (typeof value !== "object" || value === null || Array.isArray(value)) {16    return {17      jsonValid: true,18      localValid: false,19      issues: ["Expected one JSON object."],20    };21  }22 23  const data = value as Record<string, unknown>;24  const issues: string[] = [];25  if (data["@context"] !== "https://schema.org") {26    issues.push("@context must be https://schema.org.");27  }28  if (data["@type"] !== "Article") {29    issues.push("@type must be Article for this demo.");30  }31  if (typeof data.headline !== "string" || data.headline.trim() === "") {32    issues.push("headline must be a nonempty string.");33  }34  return { jsonValid: true, localValid: issues.length === 0, issues };35}

Üç katmanı birbirinden ayırın. Birincisi JSON sözdizimi: JSON.parse başarısız olursa jsonValid ve localValid ikisi de false olur. İkincisi kökün tek bir nesne olması: null, dizi, sayı ya da düz metin geçerli JSON'dur (jsonValid: true), ama bu politikayı geçmez. Üçüncüsü yerel Article politikası: @context tam olarak https://schema.org metni, @type tam olarak Article olmalı ve headline boş olmayan bir metin olmalı. Üç sorun da tek seferde issues listesine eklenir; çekirdek ilk hatada durmaz.

JSON.parse sonucunu unknown türüne bağlıyoruz; derleyici türü doğrulamadan değere dokunmamıza izin vermez. Önce typeof, null ve Array.isArray ile kökün bir nesne olduğunu doğruluyor, ancak ondan sonra Record<string, unknown> olarak yorumluyoruz. Bu as bir kanıt değil bir beyandır; güvenceyi öncesindeki denetimler sağlar.

Asıl ders sonucun alan adlarında: jsonValid, localValid ve issues ayrı kalır, çünkü geçerli JSON yerel politikayı geçmek demek değildir; yerel politikayı geçmek de tam JSON-LD uyumu ya da Google zengin sonuç uygunluğu anlamına gelmez. Bu demo tek bir nesneyi, tam https://schema.org bağlam metnini, @type: Article değerini ve boş olmayan bir headline'ı denetler. Bağlam ya da tür dizilerini, @graph'ı, JSON-LD genişletmeyi, uzak bağlamları, her Schema.org türünü ve Google'ın bütün gereksinimlerini bilerek uygulamaz. Geçerli bir JSON-LD belgesi bu politikayı bilerek geçemeyebilir; testler tür ve bağlam dizilerinin reddedildiğini açıkça sınar.

headline zorunluluğu bir öğretici politikasıdır; tek başına Google'ın Article gereksinimlerini karşıladığı iddiası değildir. Bir özelliğe uygunluk ile sonuçlarda görünme ayrı konulardır; Google'ın yapılandırılmış veriye giriş belgesi bunları kendi sözleriyle anlatır.

Sitedeki JSON-LD Doğrulayıcı farklı ve çok daha yetenekli bir araçtır: sözdizimini satır ve sütun konumuyla, JSON-LD yapısını ve Schema.org değer türlerini denetler, Google profillerini ayrı gösterir. Buradaki demo onun uygulaması ya da küçültülmüş hâli değil, yalnızca araç zincirini göstermek için yazılmış küçük bir çekirdektir.

Klasik kurulumu önce doğrulayın

Göçten önce bir başlangıç çizgisi çizin: aynı uygulama klasik araçlarla çalışıyor mu? Bu bölümdeki jsonld-demo, bilerek eski sürümlere sabitlenmiş bir deney düzeneğidir: Vite 8.3.4, Vitest 4.1.10, ESLint 9.39.1, Prettier 3.6.2, TypeScript 5.9.3 ve typescript-eslint 8.46.1. Bunlar bir göç örneği için seçildi, yeni projeler için öneri değildir; kurulumda npm, ESLint 9.39.1 için bir kullanımdan kaldırma uyarısı da yazdı.

01{02  "name": "jsonld-demo",03  "private": true,04  "version": "0.0.0",05  "type": "module",06  "packageManager": "[email protected]",07  "scripts": {08    "dev": "vite",09    "build": "vite build",10    "preview": "vite preview",11    "check": "prettier --check . && eslint . && tsc --noEmit",12    "format": "prettier --write .",13    "test": "vitest run"14  },15  "devDependencies": {16    "@eslint/js": "9.39.1",17    "eslint": "9.39.1",18    "prettier": "3.6.2",19    "typescript": "5.9.3",20    "typescript-eslint": "8.46.1",21    "vite": "8.3.4",22    "vitest": "4.1.10"23  }24}

check betiği üç ayrı komutu && ile zincirler: biçim denetimi, ESLint ve tsc --noEmit. test betiği vitest run çalıştırır. Yapılandırma üç ayrı yerde durur:

01import { defineConfig } from "vitest/config";02 03export default defineConfig({04  test: {05    environment: "node",06    include: ["src/**/*.test.ts"],07  },08});

01import js from "@eslint/js";02import tseslint from "typescript-eslint";03 04export default tseslint.config(05  { ignores: ["dist/**"] },06  js.configs.recommended,07  ...tseslint.configs.recommended,08);

01{02  "semi": true,03  "singleQuote": false,04  "printWidth": 10005}

Test dosyası, 7. bölümdeki son hâliyle aynıdır; tek fark ilk satırıdır. validate.ts, main.ts, index.html ve tsconfig.json göçten önce ve sonra bayt bayt aynı kaldı.

01import { describe, expect, it } from "vitest";

Kurulum ve biçimlendirmeden sonra klasik düzenek temiz bir npm run check verdi, npm run build başarıyla bitti ve test çıktısı şöyleydi:

01$ npm test02> [email protected] test03> vitest run04 05 06 RUN  v4.1.10 /tmp/viteplus-research-oyosbm_d/jsonld-demo07 08 09 Test Files  1 passed (1)10      Tests  17 passed (17)11   Start at  17:43:0612   Duration  100ms (transform 14ms, setup 0ms, import 22ms, tests 4ms, environment 0ms)

Başlangıç çizgimiz: 17/17 test, temiz statik kontrol, başarılı üretim derlemesi. Göçten önce özgün package-lock.json dosyasını ve kurulu Vitest 4.1.10'u silmedim; denediğim durum buydu, siz de silmeyin.

vp migrate ve değişikliklerin incelenmesi

Mevcut projeyi taşımak tek komut: vp migrate. Belgeler komutun monorepo kökünde çalıştırılmasını söylüyor ve başlangıç olarak Vite 8+ ile Vitest 4.1+ varsayıyor; klasik düzeneğimiz bunu karşılıyordu. Etkileşimsiz biçimini çalıştırdım:

01$ vp migrate --no-interactive --no-agent --no-editor --no-hooks02●  Prettier configuration detected. Auto-migrating to Oxfmt...03●  Formatting code...04●  Code formatted05◇ Migrated . to Vite+ 1.1.006• Node 24.11.0  npm 11.6.107✓ Dependencies installed in 58s08• 3 config updates applied, 2 files had imports rewritten09• ESLint rules migrated to Oxlint10• Prettier migrated to Oxfmt11! Warnings:12  - Skipped 2 rules:13    - 2 Unsupported14      - no-dupe-args: Superseded by strict mode.15      - no-octal: Superseded by strict mode.

Geçişin sonucuyla yetinmeyin; çıktıyı da okuyun. Araç Prettier yapılandırmasını bulup Oxfmt'a, ESLint kurallarını Oxlint'e taşıdı; üç yapılandırma güncellemesi uyguladı ve iki dosyada import'ları yeniden yazdı: yapılandırma dosyası ile test dosyası. Son satırlar bir uyarı: iki kural atlandı, no-dupe-args ve no-octal. Aracın tanısına göre katı kip bu kuralların işlevini zaten karşılıyor; onlar için ayrıca bir şey yapmadım.

Üretilen package.json aşağıda; olduğu gibi, düzeltmeden bıraktım.

01{02  "name": "jsonld-demo",03  "private": true,04  "version": "0.0.0",05  "type": "module",06  "packageManager": "[email protected]",07  "scripts": {08    "dev": "vp dev",09    "build": "vp build",10    "preview": "vp preview",11    "check": "vp fmt --check . && vp lint . && tsc --noEmit",12    "format": "vp fmt .",13    "test": "vp test run"14  },15  "devDependencies": {16    "typescript": "5.9.3",17    "vite": "npm:@voidzero-dev/[email protected]",18    "vite-plus": "1.1.0"19  },20  "overrides": {21    "vite": "npm:@voidzero-dev/[email protected]"22  }23}

Betikler vp komutlarına çevrildi. eslint, prettier, @eslint/js, typescript-eslint ve vitest geliştirme bağımlılıklarından çıktı; typescript yerinde kaldı. vite artık npm:@voidzero-dev/[email protected] takma adıdır ve aynı değer overrides altında da yazılıdır; vite-plus 1.1.0 olarak eklendi. Yani proje Vite'ı Vite+ çekirdeği üzerinden alıyor: vp --version ayrı yayımlanan 8.3.4'ü değil, Vite+ 1.1.0'ın getirdiği 8.3.3'ü gösteriyor. Göç eslint.config.js ve .prettierrc.json dosyalarını da kaldırdı; tsconfig.json duruyor.

Yapılandırma tek vite.config.ts dosyasında toplandı. Üretilen dosya taşınan lint kurallarının uzun bir listesini de içerdiği için burada iki alıntı veriyorum; ikisi de harfi harfine kopyalandı, atlanan kural listesini kendi yazdığım kısa bir yapılandırmayla değiştirmedim.

01import { defineConfig } from "vite-plus";02 03export default defineConfig({04  lint: {05    plugins: ["oxc", "typescript", "unicorn"],06    categories: {07      correctness: "warn",08    },09    env: {10      builtin: true,11    },12    ignorePatterns: ["dist/**"],

01    options: {02      typeAware: true,03      typeCheck: true,04    },05    jsPlugins: [06      {07        name: "vite-plus",08        specifier: "vite-plus/oxlint-plugin",09      },10    ],11  },12  fmt: {13    semi: true,14    singleQuote: false,15    printWidth: 100,16    sortPackageJson: false,17    ignorePatterns: [],18  },19  test: {20    // Vitest v4 compatibility: preserve mock call history.21    // Remove after tests no longer rely on calls from setup or earlier tests.22    // https://viteplus.dev/guide/vitest-v5#remove-unneeded-compatibility-settings23    // https://vitest.dev/guide/migration/#clearmocks-is-enabled-by-default24    clearMocks: false,25    environment: "node",26    include: ["src/**/*.test.ts"],27  },28});

Dikkat edilecek yerler: lint.options altında hem typeCheck hem typeAware açık. fmt bölümü Prettier'daki semi, singleQuote ve printWidth ayarlarını taşıyor. test bölümü eski environment ve include değerlerini korurken bir de clearMocks: false ekledi.

Bu satırı ben yazmadım: göç, Vitest v4 uyumluluğu için sahte çağrı geçmişini korumak amacıyla ekledi; yanındaki yorum ne zaman kaldırılabileceğini söylüyor. Testlerimiz sahte nesne kullanmıyor, yine de ayarı bıraktım. Kaldırmak ayrıca doğrulanması gereken bir değişiklik olurdu ve bu temizliği denemedim.

Bu, tek bir projede gözlenen bir sonuçtur. ESLint ya da Prettier eklentileriniz ve özel kurallarınız için eşdeğerlik sözü vermez; farkı satır satır okuyun, atlanan kuralları ve eklenen ayarları kendi projenizde değerlendirin.

Tek girişten kontrol, test ve build

Göçten sonra doğrulama üç komuta iner. Önce testin kendisi: son test dosyası aşağıda, ilk satır dışında klasik dosyayla aynı.

01import { describe, expect, it } from "vite-plus/test";02import { validateJsonLd } from "./validate";03 04const article = {05  "@context": "https://schema.org",06  "@type": "Article",07  headline: "A small toolchain example",08};09 10describe("validateJsonLd", () => {11  it.each(["{", "", '{"headline": }'])("rejects malformed JSON %j", (source) => {12    expect(validateJsonLd(source)).toEqual({13      jsonValid: false,14      localValid: false,15      issues: ["Invalid JSON."],16    });17  });18 19  it.each(["null", "[]", "42", '"text"'])("rejects a non-object root %j", (source) => {20    expect(validateJsonLd(source)).toEqual({21      jsonValid: true,22      localValid: false,23      issues: ["Expected one JSON object."],24    });25  });26 27  it("accepts the local Article policy", () => {28    expect(validateJsonLd(JSON.stringify(article))).toEqual({29      jsonValid: true,30      localValid: true,31      issues: [],32    });33  });34 35  it("reports every missing local field", () => {36    expect(validateJsonLd("{}").issues).toHaveLength(3);37  });38 39  it("rejects another context", () => {40    expect(41      validateJsonLd(JSON.stringify({ ...article, "@context": "https://example.com" })).issues,42    ).toContain("@context must be https://schema.org.");43  });44 45  it("rejects another type", () => {46    expect(validateJsonLd(JSON.stringify({ ...article, "@type": "Product" })).issues).toContain(47      "@type must be Article for this demo.",48    );49  });50 51  it.each([undefined, "", "   ", 12])("rejects an invalid headline %j", (headline) => {52    expect(validateJsonLd(JSON.stringify({ ...article, headline })).issues).toContain(53      "headline must be a nonempty string.",54    );55  });56 57  it("does not support type arrays in this local policy", () => {58    expect(validateJsonLd(JSON.stringify({ ...article, "@type": ["Article"] })).localValid).toBe(59      false,60    );61  });62 63  it("does not support context arrays in this local policy", () => {64    expect(65      validateJsonLd(JSON.stringify({ ...article, "@context": ["https://schema.org"] })).localValid,66    ).toBe(false);67  });68});

17 durum şunlardan oluşur: üç bozuk JSON, dört nesne olmayan kök, bir kabul, eksik alanların topluca raporlanması, başka bağlam, başka tür, dört geçersiz headline ve tür ile bağlam dizilerinin reddi. Durumlar göçte olduğu gibi kaldı; yalnızca describe, expect ve it artık vitest yerine vite-plus/test'ten geliyor.

vp check biçimi ve lint'i birlikte çalıştırır. Örnek yapılandırmada lint.options.typeCheck açık olduğu için tür denetimleri de dahildir. typeAware tür bilgisi gerektiren kuralları açan ayrı bir seçenektir ve o da açık; bu yolu oxlint-tsgolint sağlar. Çıktı:

01$ vp check02note: You are running `vp check` as a Vite+ built-in command. If you meant to run the check npm script, use `vpr check` instead.03pass: All 7 files are correctly formatted (319ms, 24 threads)04pass: Found no warnings, lint errors, or type errors in 4 files (317ms, 24 threads)

İlk satır önemli bir ayrımı hatırlatıyor: çıplak vp check, Vite+'ın yerleşik birleşik komutudur. package.json'daki check betiği ise göçten sonra hâlâ ayrı bir komut dizisidir (vp fmt --check . && vp lint . && tsc --noEmit) ve ben onu normalleştirmedim. Aynı adlı paket betikleri yerleşik komutların yerine geçmez; proje betiğini çalıştırmak için vp run <betik> ya da vpr <betik> kullanın. vp check --fix sorunları düzeltmeyi dener; --fix olmadan komut denetler, dosyaları bilerek yeniden yazmaz.

vp test --run paketlenmiş Vitest'i bir kez çalıştırır; --run bayrağı etkileşimli izleme oturumunu önler.

01$ vp test --run02note: You are running `vp test` as a Vite+ built-in command. If you meant to run the test npm script, use `vpr test` instead.03 04 RUN  v5.0.3 /tmp/viteplus-research-oyosbm_d/jsonld-demo05 06 07 Test Files  1 passed (1)08      Tests  17 passed (17)09   Start at  17:44:3510   Duration  113ms (transform 53%, import 25%, tests 14%, worker 8%)

vp build üretim derlemesini yapar ve dist/ altına çıktı yazar. Başarılı bir derleme tür doğruluğunun ya da davranışın kanıtı değildir; bu yüzden statik denetimi ve testi ayrı kapılar olarak tutuyoruz.

01$ vp build02note: You are running `vp build` as a Vite+ built-in command. If you meant to run the build npm script, use `vpr build` instead.03transforming...04✓ 5 modules transformed.05rendering chunks...06computing gzip size...07dist/index.html                0.83 kB │ gzip: 0.48 kB08dist/assets/index-DLmJpvNw.js  1.49 kB │ gzip: 0.76 kB09 10✓ built in 32ms

Diğer komutlara kısaca bakalım. vp dev geliştirme sunucusunu, vp preview üretim derlemesinin yerel önizlemesini açar. vp pack, tsdown tabanlı kütüphane iş akışıdır; bu küçük arayüz için gerekmedi. vp run proje betiklerini çalıştırır, vp toolchain etkin yerel sürümleri gösterir. Bunlar belgelere dayanır; vp dev, vp preview ve vp pack doğrulama kaydında yer almıyor.

Çıktılardaki süreler bu makinede, bir kez ölçüldü: her biri o aşamada çalıştırılan komutun kendi bildirdiği süredir; dış bir kronometre ya da karşılaştırmalı ölçüm kullanılmadı. Önbellekler ve süreç başlatma maliyetleri aşamadan aşamaya farklıdır; bu yüzden aşamaları ya da klasik ile göç sonrası süreleri birbirine kıyaslamayın. Yazının hız iddiası yoktur. Anlamlı sonuç şu: klasik ve göç sonrası düzenek 17/17 testi, temiz kontrolleri ve başarılı bir derlemeyi verdi; aynı uygulamayı taşıyan fresh-demo da aynı üç kapıdan geçti.

GitHub Actions ve GitLab CI

Aşağıdaki iki yapılandırma resmî CI kılavuzundan ve sürüme bağlı setup-vp girdi tanımlarından uyarlanmış, belgelenmiş yapılandırmalardır; uzak CI'da çalıştırılmadı. Komutların kendisini (vp install --frozen-lockfile, vp check, vp test --run, vp build) yerelde çalıştırdım ve hepsi başarılı oldu; YAML dosyalarını ne GitHub'a ne GitLab'a gönderdim. Bunlar başarılı bir uzak çalıştırmanın görüntüsü değil, önerilen bir dizilimdir: kurulum, kontrol, test, build; dağıtım adımı yok.

01name: CI02on: [push, pull_request]03permissions:04  contents: read05jobs:06  verify:07    runs-on: ubuntu-latest08    steps:09      - uses: actions/checkout@v410      - uses: voidzero-dev/[email protected]11        with:12          version: '1.1.0'13          node-version: '24.11.0'14          cache: true15          run-install: false16      - run: vp install --frozen-lockfile17      - run: vp check18      - run: vp test --run19      - run: vp build

voidzero-dev/[email protected] tam bir sürüm etiketidir ve denetim sırasında en güncel setup-vp sürümüydü (21 Eylül 2026'da yayımlandı). Eski kayan @v1 etiketi artık güncelleme almıyor; tam bir etiket ya da commit kullanın. version: '1.1.0' Vite+ sürümünü, node-version: '24.11.0' Node'u sabitler. setup-vp normalde bağımlılıkları kendisi kurar; burada run-install: false ile bunu kapattım ki sıkı kilit dosyası kapısı görünsün ve kurulum iki kez yapılmasın. actions/checkout@v4 somut bir örnektir, en güncel sürüm olduğu iddiası değildir; gerçek bir depoda onaylı bir tam SHA seçebilirsiniz. Adımlar sırayla çalışır, biri başarısız olursa iş durur.

01include:02  - remote: 'https://raw.githubusercontent.com/voidzero-dev/setup-vp/v1.21.1/gitlab/setup-vp.yml'03    inputs:04      setup-ref: 'v1.21.1'05      version: '1.1.0'06      run-install: 'false'07 08verify:09  extends: .setup-vp10  image: node:24.11.011  script:12    - vp install --frozen-lockfile13    - vp check14    - vp test --run15    - vp build16  artifacts:17    paths:18      - dist/

GitLab tarafında uzak include ile setup-ref aynı etikete (v1.21.1) işaret etmeli. Şablon Node'u kurmaz; Node'u iş imajı sağlar (image: node:24.11.0). Şablon GitLab önbelleğini de kendiliğinden yapılandırmaz: bu minimal örnekte bağımlılık önbelleği yoktur ve onu çalıştırıcınızın önbellek politikasıyla ayrıca ekleyebilirsiniz. artifacts yalnızca dist/ çıktısını saklar.

Bir ayrım daha: bağımlılık önbelleği (paket yöneticisinin verisi) ile görev sonucu önbelleği (Vite Task'ınki) ayrı kavramlardır. vp install --frozen-lockfile göç sonrası projede yerelde başarılı oldu; npm bazı geçişli paketler için kullanımdan kaldırma uyarıları yazdı. Uzak ortamda hiçbirini denemedim: GitHub ya da GitLab çalıştırıcısı tetiklenmedi, uzak önbellek servisi denenmedi ve Linux x64 dışında platform çalıştırılmadı.

Geçiş kararı ve alıştırmalar

Göç kararı bir hız vaadine değil, kanıta dayanmalı. Bu denemeden çıkan kontrol listesi:

• Çalışma zamanı: Node ^22.18.0 || ^24.11.0 || >=26.0.0 aralığında mı ve paket yöneticinizin alt sınırı karşılanıyor mu?
• Davranış: aynı testler göçten önce ve sonra aynı sonucu veriyor mu (burada 17/17)?
• Uyarılar: atlanan kurallar, yeniden yazılan import'lar ve eklenen uyumluluk ayarları okundu mu?
• Kilit dosyası: depoda mı ve CI --frozen-lockfile ile mi kuruyor?
• Sürüm hizası: vp --version beklediğiniz Vite ve Vitest sürümlerini gösteriyor mu?
• Statik kontrol: typeCheck ve typeAware bilinçli olarak açık ya da kapalı mı?
• Projeye özgü parçalar: Vite ve ESLint eklentileri ile framework varsayımları ayrıca doğrulandı mı?

Kapsam da açık: bu yazı küçük bir TypeScript uygulamasını, tek bir Linux x64 makinede, Node 24.11.0 ve npm 11.6.1 ile denedi. Framework, monorepo, başka işletim sistemleri, uzak CI ve tarayıcı davranışı denenmedi; bunlar için kendi doğrulamanız gerekir.

JSON-LD tarafında işiniz varsa sitedeki JSON-LD Doğrulayıcı'yı ve JSON Biçimlendirici ve Doğrulayıcı'yı kullanabilirsiniz; ikincisi JSON'u biçimlendirir ve hatayı satır ile sütun olarak gösterir. Bu yazıdaki demo onların yerini tutmaz.

Özetle: araç zincirini birleştirmek ayar dosyalarını ve komutları azaltabilir, ama neyi doğruladığınızı bilmek yine sizin işiniz. Ölçü şu: 17/17 test, temiz statik kontrol, başarılı derleme ve okunmuş bir fark.