‏Vitest بدون Vite؟ پیشنهاد جدید برای معماری Framework-Agnostic

یکی از مینتینرهای اصلی Vitest، یه پروپوزال جدید توی گیت‌هاب مطرح کرده که می‌تونه آینده این تست‌رانر محبوب رو کاملاً عوض کنه. ایده اصلی اینه که Vitest از وابستگی ذاتیش به Vite جدا بشه و به یه معماری Framework-Agnostic برسه.

تا الان، اینکه Vitest روی Vite ساخته شده بود هم یه مزیت بزرگ بود (HMR فوری، کانفیگ یکپارچه، اکوسیستم مشترک پلاگین‌ها) و هم یه محدودیت جدی. اگه پروژه‌ات مثلاً روی Webpack بود، یه سرویس خالص Node داشتی، یا می‌خواستی با Deno یا Bun کار کنی، مجبور بودی کل پایپلاین Vite رو تحمل کنی، حتی اگه بهش نیازی نداشتی.

راه‌حل پیشنهادی یه فلگ جدید به اسم --framework هست که می‌شه اینطوری استفاده کرد:

vitest --framework @vitest/framework-node
vitest --framework @vitest/framework-vite  # پیش‌فرض
vitest --framework @web-infra-dev/vitest-framework-rsbuild

هر «فریم‌ورک» در واقع یه پکیج npm عادیه که یه سری قرارداد ثابت با هسته Vitest داره. این پکیج مسئوله که کانفیگ کاربر رو لود کنه، ماژول‌ها رو ترنسفورم کنه، سیستم watch رو مدیریت کنه، و منابع رو موقع بسته شدن آزاد کنه. Vitest هم فقط با همین قرارداد کار می‌کنه و کاری به اینکه زیرش چی هست نداره.

این ایده از پروژه unplugin الهام گرفته، که بهت اجازه می‌ده یه پلاگین رو برای چند ابزار build مختلف بنویسی. اینجا هم همون منطق «یه اینترفیس کوچک و پایدار بین هسته و آداپتورها» دنبال شده.

نکته مهم اینه که این تغییر هیچ breaking changeای برای کاربرهای فعلی نداره. اگه --framework رو ننویسی، Vitest همون @vitest/framework-vite رو لود می‌کنه که دقیقاً همون رفتار الان رو داره، یعنی همون vite.config.ts و vitest.config.ts و فیلد test.

اولین آداپتور غیر-Vite که احتمالاً شیپ می‌شه، @vitest/framework-node هست که در واقع همون حالت viteModuleRunner: false فعلی رو به یه فریم‌ورک مستقل تبدیل می‌کنه. این یعنی می‌تونی Vitest رو با native TypeScript loader نود استفاده کنی، بدون اینکه Vite یا Rolldown اصلاً نصب بشن.

بخش‌هایی مثل test runner، expect، mocking، snapshots، reporters، UI و coverage هیچ تغییری نمی‌کنن چون اصلاً به Vite وابسته نیستن. فقط لایه ترنسفورم و رزولوشن ماژول‌هاست که انتزاعی می‌شه.

چند تا سوال باز هنوز هست که باید تو مرحله پیاده‌سازی حل بشن: شکل دقیق قرارداد فریم‌ورک (که بعد از ساختن حداقل دو آداپتور واقعی مشخص می‌شه)، اینکه --framework رو کجا غیر از CLI بشه تعریف کرد (env var؟ فایل marker؟ فیلد package.json؟)، و اینکه آپشن‌های اختصاصی هر فریم‌ورک چطور به کانفیگ کاربر برسن بدون اینکه تایپ‌های Vitest core آلوده بشن.

نکات کلیدی:

• پیشنهاد اضافه کردن فلگ --framework به Vitest برای جدا کردن از Vite
• Vite همچنان پیش‌فرض می‌مونه؛ هیچ تغییری برای کاربرهای فعلی نیست
• هر فریم‌ورک یه پکیج npm مستقله که قرارداد مشخصی با هسته Vitest داره
• فریم‌ورک‌های هدف: Node خالص، Deno، Bun، Webpack، esbuild، Rsbuild، Rolldown، Oxc
• اولین آداپتور: @vitest/framework-node بر پایه حالت viteModuleRunner: false فعلی
• الهام گرفته از معماری پروژه unplugin
• شکل دقیق قرارداد فریم‌ورک بعد از پیاده‌سازی دو آداپتور واقعی نهایی می‌شه