TL;DR: هیچی!
Angular 15 به سادگی دیگر فایل های محیطی را به طور پیش فرض ارسال نمی کند.
همچنان می‌توانید آنها را ایجاد کنید و جایگزینی آنها را بر اساس هدف ساخت پیکربندی کنید، همانطور که در نسخه‌های قبلی در زمان ایجاد پروژه به طور خودکار انجام می‌شد.
هدفی که درک نشده است
منشأ سردرگمی، اخیراً در مورد گم شدن این پرونده ها در پروژه جدید ایجاد شده با ng-cli در نسخه 15، ریشه در این تصور غلط دارد که src/environments/environment.ts و src/environments/environment.prod.ts نوعی مسیر مقدس بود که در عمیق‌ترین چارچوب Angular کدگذاری شده بود.
واقعیت این است که آنها فقط یک انتخاب پیش‌فرض راحت بودند، بدون هیچ مرجعی در پایگاه کد، و می‌توانستند با مسیرها و نام‌های مختلف جایگزین شوند، بدون اینکه آسیبی به برنامه وارد شود.
نقش اصلی
تنها جایی در کد که می‌توانستید آنها را در هنگام ایجاد پروژه به آنها ارجاع دهید، بود main.ts، با چیزی شبیه به این تولید می شود:
...
import { environment } from './environments/environment';
if (environment.production) {
enableProdMode();
}
...
آنها environment.production از ویژگی برای بررسی اینکه آیا بیلد تازه بوت شده باید فعال شود یا خیر استفاده شد ProdMode یا نه.
این عملکرد یک پرچم را خاموش می کرد (بله، پرچم در واقع است isDevMode، و نه isProdMode همانطور که می توان انتظار داشت) در واقع در Angular codebase بررسی شد تا برخی از ویژگی های “اشکال زدایی” را تغییر دهد، که واضح ترین آنها مطمئناً پیام آشنای وارد شده در کنسول است.
Angular در حالت توسعه اجرا می شود. برای فعال کردن حالت تولید، enableProdMode() را فراخوانی کنید.
وقتی پرچم است true، به این معنی است که ما در حال اجرای یک مرحله توسعه از برنامه خود هستیم، بنابراین می خواهیم چارچوب در هشدارها و خطاها واضح تر باشد، و حتی بررسی موقعیت هایی که به خودی خود خطا نیستند، کمی “پندانه تر” باشد، اما می تواند منجر به رفتار نامطلوب و اغلب اشتباه در تولید شود.
یکی از معروف‌ترین آنها مطمئناً NG0100 است: عبارت پس از بررسی تغییر کرده است، و مسئول تأیید صحت اتصال داده‌های ما از یک جریان یک طرفه است، چیزی که میتوانست در حین اجرا مشکلاتی ایجاد می کند، اما در زمان اجرا به خودی خود خطا ایجاد نمی کند.
در ابتدا Angular هیچ راهی برای تغییر این پرچم نداشت جز قرار دادن تابع در یک فایل تجزیه شده در بوت استرپ.
جادوی سیاه تعویض فایل
مردم تمایل به پذیرش تفسیر داشتند
فایل صحیح برای بارگذاری به عنوان ایمان، بدون سوال چگونه چارچوب قادر به خواندن بود environment.ts یا environment.prod.ts مطابق با هدف ساخت انتخابی.
پاسخ چیزی شامل درک عمیق مکانیزم های داخلی Angular نبود، بلکه فقط استفاده از یک ویژگی خوب ارائه شده توسط سازنده آن، که پیکربندی تجزیه برای انتخاب هدف، دستور داده شد که در نظر گرفته شود. fileReplacements آرایه، جایگزینی تعریف شده در اشیاء خود را صادر می کند.
این پیکربندی پیش فرض برای بود تولید ساخت چند نسخه قبل:
"configurations": {
...
"production": {
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.prod.ts"
}
],
...
هیچ چیز مانع از اضافه کردن جایگزین های جدید یا تغییر یک جایگزین جدید نشد، اما اگر مورد دوم بود، باید اصلاحات خود را در نظر می گرفتیم. main.ts برای بررسی فایل مناسب برای environment.production دارایی که برای تغییر پرچم تولید استفاده می کرد.
آنچه در نسخه 15 تغییر کرد
آخرین نسخه اصلی Angular از یک سیستم متفاوت برای تغییر پرچم تولید استفاده می کند: اجازه می دهد optimization گزینه builder، به طور پیش فرض به production ساخت هدف، تنظیم جهانی NgDevMode به false، بدون نیاز به تجزیه هیچ فایل env.
این تغییر تنها دلیل وجود هر گونه فایل محیطی در ابتدا را از بین برد و باعث شد توسعه دهندگان به طور کامل از شر آنها خلاص شوند و بدیهی است که پیش فرض را حذف کنند. fileReplacements وقوع در پیکربندی اهداف ساخت.
چرا مردم عصبانی می شوند
با نگاهی به آنچه تاکنون خواندیم، به نظر می رسد که این رویکرد جدید چیزی نیست که بر اکثر توسعه دهندگان برنامه های Angular تأثیر بگذارد، زیرا بیشتر یک «داخلی» چارچوب است.
موضوع این است که از آنجایی که این فایل‌ها قبلاً در زمان ایجاد پروژه تولید شده‌اند و به درستی بر اساس هدف ساخت مدیریت می‌شوند، استفاده از آنها برای ذخیره مجموعه‌ای از مقادیر که نیاز به جابجایی بین تولید و ساخت توسعه دارند، به یک روش معمول تبدیل شده است.
معمولاً اینها شامل آدرس سرورهای API برای تماس و تنظیمات ارائه دهندگان تأیید اعتبار می شود.
بدون یافتن فایل‌هایی که در پروژه‌های تازه تولید شده انتظار می‌رفت، افرادی که هرگز علاقه‌مند به درک نحوه کارشان نبودند، نمی‌دانستند این داده‌ها را کجا قرار دهند، غافل از سادگی بازتولید دستی تنظیمات اصلی.
راه حل تنبل
پس از حجم عظیمی از شکایات در این مورد، توسعه دهندگان Angular تصمیم می گیرند تا در صورت تقاضا چیزی شبیه به رفتار قدیمی در نسخه 15.1 را “بازیابی” کنند.
بنابراین، از آن نسخه به بعد، وجود فایل های محیطی پس از ایجاد پروژه به سادگی صدور است
ng generate environments
که همانطور که در اسناد توضیح داده شد آنها را ایجاد و پیکربندی می کند build و server اهداف استفاده از آنها
به طور خلاصه: ایجاد خواهد کرد src/environments/environment.ts و src/environments/environment.development.ts اضافه کردن دومی به عنوان جایگزین اولی برای پیکربندی ساخت development هدف
"development": {
...
"fileReplacements": [
{
"replace": "src/environments/environment.ts",
"with": "src/environments/environment.development.ts"
}
]
چرا قبلاً به آن فکر نمی کردند
عادت قرار دادن متغیرهای محیطی در داخل آن فایل‌ها، ساده‌تر از آن چیزی است که به نظر می‌رسد.
حتی اگر نام و استفاده از آنها می تواند منجر به نگاه کردن به آنها به عنوان نقطه ایده آل برای چنین اطلاعاتی شود، در سناریوی واقعی آنها از بهترین راه حل دور هستند.
داده هایی مانند دامنه ها، نقاط پایانی، پورت ها و موارد مشابه فقط به آن محدود نمی شوند ساختمان هدف قرار دهید، اما اغلب محکم تر به زمینه استقرار.
به همین دلیل است که بسیاری از مردم ترجیح می دهند آنها را خارج از فرآیند ساختن نگه دارند و به برنامه اجازه دهند که آنها را در زمان اجرا به عنوان نشانه ای که در هنگام استقرار تزریق می شود ارزیابی کند، شاید به عنوان متغیر محیطی چارچوب میزبانی یا بسته بندی داکر، توسط یک فرآیند حداقل سمت سرور خوانده شود و به عنوان API در معرض دید قرار گیرد. ، یا حتی ارسال آنها در فایل پیکربندی اختصاصی که به عنوان دارایی توسط خط لوله درج شده است، همانطور که در این مقاله عالی از good ol’ @frederikprijck توضیح داده شده است.
اکنون باید مشخص شود که هیچ تغییری در مدیریت متغیرهای محیطی توسط Angular ایجاد نشده است، فقط یک ارتقاء که باعث شد دیگر به پیکربندی کالای قدیمی نیازی نباشد، و منجر به تجدید نظر در عادتی شد که اغلب یک راه‌حل غیربهینه بود، اما در حال حاضر در دسترس است. همیشه بوده است
به سلامتی.
