توسعه محلی با zinnector dev

دستور zinnector dev یک نسخه واقعی از WordPress را روی دستگاه شما اجرا می‌کند، افزونه‌ها و پوسته‌های پروژه شما را با نسخه PHP دلخواهتان میزبانی می‌کند. این مقاله دو محیط اجرایی را که می‌تواند استفاده کند، نحوه انتخاب نسخه‌ها، نحوه میزبانی از فایل‌ها و محل قرارگیری محیط اجرایی روی دیسک شرح می‌دهد تا آنچه به‌صورت محلی تست می‌کنید، دقیقاً همان چیزی باشد که مستقر می‌سازید.

دو محیط اجرایی و دلیل واقعی بودن هر دو

گزینه Playground پیش‌فرض است. محیط WordPress Playground کد PHP را به WebAssembly کامپایل کرده و آن را در Node اجرا می‌کند، بنابراین یک لپ‌تاپ که فقط Node روی آن نصب شده است، می‌تواند در عرض چند ثانیه یک WordPress را راه‌اندازی کند. هر نسخه PHP از ۵.۲ تا ۸.۵ در دسترس است. این محیط مجموعه‌ای کوچک از افزونه‌های PHP (شامل intl، redis و memcached بر اساس اندازه‌گیری روی بیلد فعلی) را به همراه دارد که برای بیشتر کارهای مربوط به افزونه و پوسته کافی است.

گزینه Docker کانتینرهای بومی php-fpm و MariaDB را اجرا می‌کند. این روش کندتر است، به یک دیمون Docker و حدود ۱.۲ گیگابایت ایمیج نیاز دارد و از PHP نسخه‌های ۷.۴ تا ۸.۵ پشتیبانی می‌کند؛ اما یک PHP بومی را با مجموعه کامل افزونه‌ها از جمله imagick و gd اجرا می‌کند. این راه حل مطمئنی است زمانی که نیاز به تست افزونه‌ای دارید که بیلد WebAssembly آن را ندارد.

zinnector dev                       # playground
zinnector dev --runtime docker      # native PHP + MariaDB

هیچ‌گاه به طور خودکار به Docker بازگشت (fallback) انجام نمی‌شود. توسعه‌دهنده‌ای که فکر می‌کند روی WebAssembly است اما در واقع روی Docker قرار دارد، پاسخ اشتباهی از ابزاری که قصد کمک دارد دریافت کرده است، بنابراین نام آن باید صراحتاً درخواست شود.

انتخاب نسخه‌های PHP و WordPress

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

مقادیر پیش‌فرض از فایل zinnector.json در پروژه (php، wordpress، runtime و port) گرفته می‌شوند که zinnector new آن را می‌نویسد و شما باید آن را کامیت کنید تا همه افراد روی پروژه نسخه‌های یکسانی را اجرا کنند. یک فلگ در خط فرمان برای آن اجرا، بر فایل ترجیح داده می‌شود.

نسخه‌ای که اعلام می‌کنید با نسخه‌ای که اجرا می‌شود دو حقیقت متفاوت هستند. دستور zinnector dev --once محیط اجرایی را بوت می‌کند، آنچه را که عملاً گزارش می‌دهد (نسخه PHP، نسخه WordPress، افزونه‌های بارگذاری‌شده) چاپ می‌کند و متوقف می‌شود. دستور zinnector check --probe هنگام مقایسه پروژه شما با یک اسلات میزبانی، از همین اندازه‌گیری استفاده می‌کند.

آنچه از پروژه شما میزبانی می‌شود

محیط اجرایی دایرکتوری‌های wp-content/plugins، wp-content/themes و wp-content/mu-plugins پروژه شما را مستقیماً مانت می‌کند، بنابراین فایلی که ذخیره می‌کنید در بارگذاری مجدد بعدی زنده است. دایرکتوری‌هایی که وجود دارند اما محتوای واقعی ندارند به صورت عمدی مانت نمی‌شوند: یک دایرکتوری خالی themes/ که روی پوسته‌های خود محیط اجرایی مانت شود، WordPress را بدون هیچ پوسته‌ای باقی می‌گذارد که به جای سایت شما، یک خطای ۵۰۰ خالی خواهد بود. به همین دلیل است که اسکلت‌بندی (scaffold) دایرکتوری‌های خالی را با یک .gitkeep نگه می‌دارد و تا زمانی که پوسته‌ای در آن‌ها قرار ندهید، روی چیزی سایه نمی‌اندازند.

محل قرارگیری محیط اجرایی

محیط اجرایی WordPress به جای اینکه به همراه CLI عرضه شود، در اولین استفاده دانلود می‌شود؛ بسته‌ای که هر بیلد PHP را حمل می‌کند حدود ۵۷۰ مگابایت است و توسعه‌دهنده‌ای که فقط لیست سایت‌ها را می‌بیند نباید هزینه آن را بپردازد. این بسته در کش اختصاصی Zinnector®، یعنی ~/.cache/zinnector/runtimes/playground/<version> (یا هر جایی که ZINNECTOR_CACHE_DIR به آن اشاره دارد) نگهداری می‌شود و هرگز در پروژه شما قرار نمی‌گیرد؛ بنابراین نمی‌تواند در مخزن (repository) شما یا در درختی که zinnector push آن را اندازه‌گیری می‌کند ظاهر شود. دانلود توسط npm خود شما و به صورت node npm-cli.js انجام می‌شود و هرگز از طریق یک شل (shell) صورت نمی‌گیرد.

نسخه محیط اجرایی به نسخه CLI سنجاق (pin) شده است، بنابراین دو توسعه‌دهنده روی یک پروژه، بیلدهای PHP یکسانی را اجرا می‌کنند. دستور zinnector dev --reset-runtime محیط اجرایی نصب‌شده را دور انداخته و دوباره نصب می‌کند که این راه حل رفع مشکل برای محیط اجرایی است که نصب شده اما بوت نمی‌شود.

روی Node نسخه ۲۶ یا جدیدتر

خود CLI روی هر نسخه Node از ۲۴ به بالا اجرا می‌شود. با این حال، ماژول بومی محیط اجرایی تنها با باینری‌های پیش‌ساخته برای Node نسخه‌های ۲۴ و ۲۵ (از سپتامبر ۲۰۲۶) عرضه می‌شود. Zinnector® به جای کامپایل کردن هر چیزی (که در ویندوز به معنای نصب Visual Studio است)، یک نسخه Node 24 را صرفاً برای محیط اجرایی (با حجم حدود ۳۰ مگابایت) که با چک‌سام‌های منتشرشده در nodejs.org تأیید شده است، به همان کش می‌آورد. پیام نصب هنگام اعمال، این موضوع را اعلام می‌کند. هیچ تغییری در Node خود شما ایجاد نمی‌شود.

مطالب مرتبط

• شروع به کار · استقرار · مرجع دستورات · عیب‌یابی