مقالات

Astro 7.4 | Astro


Astro 7.4 اینجاست! ویژگی عنوان جدید است --timings پرچم برای astro build که دقیقاً نشان می دهد که ساخت شما زمان خود را در کجا می گذراند. این نسخه همچنین به شما امکان می دهد از خدمات تصویری مختلف برای صفحات پیش رندر و درخواستی استفاده کنید notFound() کنترل کننده نقاط ورودی سفارشی و به شما در مورد تنظیمات فونتی که ارائه دهنده شما نمی تواند پشتیبانی کند هشدار می دهد. دو ویژگی آزمایشی جدید آن را تکمیل می‌کنند: پیش‌اجرای موازی در رشته‌های کارگر و صفحه تغییر مسیر سفارشی برای ساخت‌های استاتیک.

بررسی کنید چه چیزی در این نسخه جدید است:

برای ارتقاء یک پروژه موجود، از خودکار استفاده کنید @astrojs/upgrade ابزار CLI. از طرف دیگر، می توانید با اجرای دستور ارتقاء برای مدیر بسته خود، به صورت دستی ارتقا دهید:

pnpm upgrade astro --latest

yarn upgrade astro --latest

زمان های ساختمانی

وقتی ساخت و ساز به تعویق می افتد، همیشه دلیل آن مشخص نیست. آیا این یک پلاگین Vite، برجسته سازی نحو، پردازش تصویر، یا ارائه یک صفحه به خصوص سنگین است؟

astro build اکنون الف را می پذیرد --timings پرچم:

وقتی ساخت کامل شد، Astro خلاصه‌ای از زمان گذشته را چاپ می‌کند: مراحل ساخت، پلاگین‌های Vite، پردازش Markdown و برجسته‌سازی نحو، رندر صفحه، تصاویر و ادغام‌ها.

در اینجا به نظر می رسد در عمل. ما وبلاگ شروع را گرفتیم و یک را اضافه کردیم جزء طرح بندی پست وبلاگ نظرات در هر پست و هر پست را بازیابی می کند داخل و سپس نمایه نظر دهنده را بازیابی می کند:

const { comment } = Astro.props;

// Look up the commenter's profile for every comment

const res = await fetch(`https://jsonplaceholder.typicode.com/users?email=${comment.email}`);

const [user] = await res.json();

strong>{user?.name ?? comment.name}strong>

هیچ چیز در این مورد در ویرایشگر اشتباه به نظر نمی‌رسد، اما درخواست‌های نمایه نمی‌توانند تا زمانی که نظرات بازنگردند شروع شوند، بنابراین هر صفحه برای دو دور متوالی وب منتظر می‌ماند. در حال اجرا astro build --timings دیدن این را آسان می کند (برخی بخش ها بریده شده اند):

total 2.61s · 9 pages · output "static"

resolve config 59ms 2.3% ▄·····················

setup 225ms 8.6% ▃█▅···················

route discovery 2ms 0.1% ▁·····················

vite config 14ms 0.5% ▁·····················

content sync 206ms 7.9% ▂█▅···················

prerender bundle 151ms 5.8% ··▃█··················

client bundle 21ms 0.8% ····▂·················

manifest injection 2ms 0.1% ····▁·················

generate pages 2.10s 80.6% ····▇█████████████████

prerenderer setup 6ms 0.2% ····▁·················

static paths 3ms 0.1% ····▁·················

Page rendering (2.09s across 9 pages)

component render 2.08s 79.6% ····▆█████████████████

Slowest pages (median 297ms · p95 571ms)

/blog/first-post 307ms /blog/[...slug]

/blog/using-mdx 303ms /blog/[...slug]

/blog/second-post 299ms /blog/[...slug]

/blog/third-post 297ms /blog/[...slug]

/blog/markdown-style-guide 296ms /blog/[...slug]

این گزارش داستان را از بالا به پایین بیان می کند. تولید صفحه 81 درصد از ساخت را به خود اختصاص می دهد و تقریباً تمام آن در داخل مؤلفه ها صرف می شود، نه خود صفحه Astro. کندترین صفحات آنهایی هستند که از طرح بندی پست وبلاگ استفاده می کنند، در حالی که /blog و /rss.xml رندر در میلی ثانیه این به طور مستقیم به چیزی که چیدمان نشان می دهد اشاره می کند.

بازیابی نظرات و تمام نمایه ها به طور همزمان با Promise.all() ج و ارسال هر نمایه به ، تولید صفحه را از 2.10 به 1.13 کاهش داد و زمان هر پست وبلاگ را به نصف کاهش داد.

این گزارش همچنین پلاگین‌های Vite، کندترین فایل‌های دسته‌ای، پلاگین‌های Markdown، برجسته‌سازی نحو و تغییر شکل‌های تصویر را پوشش می‌دهد، بنابراین همان پرچم به شما کمک می‌کند که ساخت کند شما از رندر، دسته‌بندی یا تصاویر باشد. این اولین قدم خوب قبل از امتحان پرچم‌هایی مانند پیش‌پرداخت موازی یا ساخت‌های افزایشی است، بنابراین می‌دانید کدام قسمت از ساخت را هدف قرار دهید. نگاه کن --timings مرجع برای اطلاعات بیشتر

خدمات ساخت و اجرای تصویر مجزا

صفحات از پیش رندر شده و صفحات درخواستی در مورد تصاویر نیازهای متفاوتی دارند. در طول ساخت، شما زمان کافی و یک محیط Node.js کامل دارید، بنابراین یک بهینه ساز محلی مانند شارپ به خوبی کار می کند. صفحات درخواستی روی سرور شما یا در لبه اجرا می شوند، اغلب در یک محیط زمان اجرا که شارپ نمی تواند اجرا شود، بنابراین CDN تصویر معمولا مناسب تر است. تا به حال، شما مجبور بودید یک سرویس تصویر را برای هر دو انتخاب کنید یا به آداپتور خود اعتماد کنید تا انتخاب را برای شما انجام دهد.

در Astro 7.4، image.service الف را نیز می پذیرد build و الف runtime خدمات:

import { defineConfig } from 'astro/config';

export default defineConfig({

build: { entrypoint: 'astro/assets/services/sharp' },

runtime: { entrypoint: 'my-image-cdn-service' },

را build این سرویس تصاویر صفحه از پیش رندر شده را مدیریت می کند، آنها را در حین ساخت تولید می کند و در طول توسعه نیز استفاده می شود. را runtime این سرویس صفحات را بر اساس تقاضا و نقطه پایانی تصویر را در تولید پردازش می کند. گذراندن یک سرویس همچنان مانند قبل کار می کند.

برای اینکه این امکان را فراهم کنیم، نحوه ردیابی Astro تصاویر استفاده شده در طول ساخت را دوباره طراحی کردیم. پیش رندرها اکنون به جای اینکه خودشان آن را بازسازی کنند، وارد خط لوله تصویربرداری خود Astro می شوند. در نتیجه @astrojs/cloudflare اکنون تصاویر صفحه از پیش اجرا شده را از طریق همان خط لوله مانند هر آداپتور دیگر کنترل می کند.

کنترل کننده notFound() برای نقاط ورودی سفارشی

دستکاری های جمع شونده در astro/fetch و astro/hono به شما این امکان را می دهد که سرور یا نقطه ورودی کاری خود را از قطعات Astro بسازید. با این حال، اگر استفاده کرده اید pages() بدون همه در یک astro() کنترل کننده، درخواستی که با هیچ مسیری مطابقت نداشت، به جای درخواست سفارشی شما، یک 404 خالی برگرداند 404.astro صفحه حتی اگر از قبل رندر شده باشد.

Astro 7.4 یک را اضافه می کند notFound() یک دستکاری کننده قبلش اضافه کنید pages() برای رندر کردن صفحه 404 خود در صورت وجود مسیر منطبق:

import { Hono } from 'hono';

import { notFound, pages } from 'astro/hono';

import { cf } from '@astrojs/cloudflare/hono';

همان هندلر در دسترس است astro/fetch. astro() در حال حاضر شامل این رفتار است، بنابراین شما فقط نیاز دارید notFound() زمانی که کنترل کننده ها را خودتان می سازید. نگاه کن notFound() مرجع برای جزئیات

هشدارهای پیکربندی فونت

درخواست وزن قلم یا زیرمجموعه ای که خانواده فونت ارائه نمی دهد آسان است و تا به حال فقط زمانی متوجه شده اید که متن اشتباه به نظر می رسد. ارائه دهندگان فونت اکنون می توانند یک گزینه را پیاده سازی کنند getFontProperties() پاسخ تماس که وزن‌ها، سبک‌ها، زیرمجموعه‌ها و قالب‌هایی را که خانواده واقعاً دارند گزارش می‌کند و Astro به شما در مورد مقادیر موجود در پیکربندی‌تان که ارائه‌دهنده نمی‌تواند ارائه دهد هشدار می‌دهد.

همه ارائه دهندگان فونت داخلی Astro از این پشتیبانی می کنند. اگر یک ارائه دهنده فونت سفارشی دارید، توصیه می کنیم آن را پیاده سازی کنید getFontProperties() اکنون در Astro 7 مورد نیاز نیست اما در Astro 8 مورد نیاز خواهد بود:

import type { FontProvider } from 'astro';

const provider: FontProvider = {

resolveFont: ({ familyName }) => {

getFontProperties: ({ familyName }) => ({

styles: ['normal', 'italic'],

را init() زمینه برای ارائه دهندگان فونت نیز به دست می آورد fetch() تابعی که خطاهای گذرا را دوباره امتحان می کند. ارائه دهندگانی که یک ارائه دهنده یونیفونت شخص ثالث را بسته بندی می کنند، می توانند متن را مستقیماً به آن منتقل کنند. برای جزئیات به مرجع فروشنده فونت مراجعه کنید.

حداقل نسخه Node.js به روز شده است

حداقل نسخه پشتیبانی شده Node.js برای Astro و ادغام های رسمی آن اکنون 22.22.0 است. این آخرین نسخه Node.js 22 است که توسط StackBlitz پشتیبانی می شود و این تغییر از خط مشی پشتیبانی Astro’s Node.js پیروی می کند. اگر از نسخه قدیمی Node.js 22 استفاده می کنید، Node.js را قبل از ارتقای Astro ارتقا دهید. پیش نیازهای نصب را برای لیست کامل الزامات مشاهده کنید.

تجربی: پیش اجرا موازی

Astro صفحات استاتیک را به طور همزمان رندر می کند، اما تاکنون تمام این رندرها در یک رشته واحد اتفاق می افتاد. در سایت‌های بزرگ با صفحات سنگین CPU، صرف نظر از اینکه دستگاه شما چند هسته داشت، ساخت به یک هسته محدود می‌شد.

Astro 7.4 اضافه می کند experimental.parallelPrerender پرچمی که صفحات ایستا را روی رشته‌های کارگر Node.js ارائه می‌کند:

import { defineConfig } from 'astro/config';

export default defineConfig({

به طور پیش فرض، Astro از تمام هسته های CPU موجود به جز یکی استفاده می کند. هر کارگر به حافظه ای که ساخت شما استفاده می کند اضافه می کند، بنابراین اگر حافظه بیلد شما تمام شد یا سریعتر نشد، تنظیم کنید workers به عدد کمتر:

import { defineConfig } from 'astro/config';

export default defineConfig({

هر کارگر به اندازه صفحه شما در یک زمان رندر می کند build.concurrency تنظیم اجازه می دهد.

وقتی آداپتور شما راه خود را برای پیش‌اجرای صفحات فراهم می‌کند، پرچم هیچ تأثیری ندارد. در میان آداپتورهای رسمی، این فقط است @astrojs/cloudflareو Astro در هنگام ساخت وقتی پرچم نادیده گرفته می شود، هشداری را ثبت می کند.

این به خوبی با ساخت‌های استاتیک افزایشی جفت می‌شود: ساخت‌های افزایشی، صفحاتی را که تغییر نکرده‌اند پرش می‌کنند، و پیش‌رندر موازی، صفحاتی را که نیاز به رندر دارند در هسته‌های CPU شما توزیع می‌کند. برای اطلاعات بیشتر به مقالات آزمایشی پیش اجرا موازی مراجعه کنید.

آزمایشی: صفحه فرود سفارشی

یک سایت استاتیک دارای سرور فشار HTTP نیست Location هدر، بنابراین برای هر تغییر مسیری که ایجاد می کند، Astro یک صفحه HTML کوچک با یک ایجاد می کند برچسب زدن این شامل مال شما نیز می شود redirects پیکربندی، Astro.redirect() تماس در صفحات از پیش اجرا شده و تغییر مسیر i18n. نشانه گذاری، جمله بندی و تأخیر این صفحه اصلاح شده است، بنابراین نمی توانید آن را تغییر نام دهید یا ترجمه کنید.

جدید experimental.redirectPage پرچم به شما امکان می دهد موارد زیر را ارائه دهید:

import { defineConfig } from 'astro/config';

export default defineConfig({

سپس ایجاد کنید src/pages/3xx.astro. Astro برای هر تغییر مسیر یک بار آن را رندر می کند و آن تغییر مسیر را منتقل می کند from، to، status، و delay به عنوان یک تکیه گاه:

import type { RedirectPageProps as Props } from 'astro';

const { from, to, status, delay } = Astro.props;

meta http-equiv="refresh" content={`${delay};url=${to}`} />

meta name="robots" content="noindex" />

title>Redirecting…title>

p>This page has moved. a href={to}>Continue to {to}a>.p>

در ساخت استاتیک، تغییر مسیر است، بنابراین صفحه شما باید صفحه ای را نشان دهد که به آن اشاره دارد to. Astro در حین ساخت اخطاری را در صورت گم نشدن ثبت می‌کند و اگر صفحه شما رندر نمی‌شود به صفحه ساخته شده باز می‌گردد. تغییر مسیرها از صفحات درخواستی بدون تغییر هستند.

برای اطلاعات بیشتر به اسناد موجود در صفحه تغییر مسیر آزمایشی مراجعه کنید و در مورد RFC بازخورد بگذارید.

سایر پیشرفت ها

  • ادغام ها می توانند دایرکتوری های منبع ساخت را کنترل کنند – Astro در حال حاضر راه حل Vite را مدیریت می کند outDir برای هر محیط به عنوان منبعی از حقیقت در مورد جایی که خروجی کلاینت، سرور و پیش رندر نوشته شده است تا ادغام ها و پلاگین های Vite بتوانند آن را جابجا کنند. پیش‌اجرای سفارشی می‌تواند مکان‌های نهایی را از جدید بخواند outputDirectories زمینه ج setPrerenderer()و مانیفست های Vite build اکنون برای همه باقی می مانند buildApp قلاب به پایان رسیده است بنابراین ادغام های استقرار می توانند آنها را بخوانند. (#18313)

برای لیست کامل رفع اشکال و بهبودهای جزئی، تغییرات کامل را ببینید.

تیم اصلی Astro عبارتند از:

الکساندر نیبور، آرماند فیلیپو، کریس سویتین بانک،
امانوئل استوپا،
اریکا، فلوریان لوفور، فرد شات،
سلام،
لویی فراز، مت کین، متیو فیلیپس،
روبن ردیف،
سارا رینزبرگر، و ایان توماس.

تشکر ویژه از همه کسانی که با کد، اسناد، بررسی‌ها و آزمایش‌ها به Astro 7.4 کمک کردند، از جمله:

آدام چالمیان، آدام متیسن، الکس هویاو، آلیسون نونس، آناستازیا ی.، آندریاس دینینگر، آندری آلبا، آنجل مارفیل، اصقر باکر، آرورا، آستن استون، بن ابوالفیا، برکن، بولبرین برند، چاودری زابر بن زاهد، دن بارکلی، دن بارکلی، دنیل بارکلی، دنیل بارکلی، دنیل بارکلی فلیکس اشنایدر، fkatsuhiro، Fuan200، جورج ژانگ، هارجوت سینگ، میزبان*هاست، جک هانفورد، جاکوبورتیز، جیمز اوپستاد، جاسین، جوئل هانسون، پارک Junseong، kdelay، کوین دنگ، KTrain، لیف مارکوس، لیانگ زو، لوئیس مانپری، لوئیز مانپری، لیانگ ژو، لوئیز مانپری سینگ، مانوئل، مائورو دانیل ویوروس، مایکل وانگ، میخائیل آلابوگین، مینگ جون لو، مینهو یو، میکستو، مرچاتام، نیل د کارترت، اوکاو، پل والادارس، پدرو اسپنگلر، پیرانات دانائدئوس، پیوش مهتا، پروتوی شتی، 265، random. Mozammel، Shinya Fujino، Shoichi Sasaki، surefirestudios، Tobias Breit، Tomoki Yamauchi، ump45nose، Wataru Sato، Waxer59، Yhvr و Zhiqi Zhang

امیدواریم از Astro 7.4 خوشتان بیاید. اگر به مشکلی برخوردید یا می‌خواهید بازخورد خود را به اشتراک بگذارید، لطفاً در Discord به ما بپیوندید، در GitHub پست کنید، یا با Bluesky تماس بگیرید. توییترو ماستودون




Source link

نوشته های مشابه

دیدگاهتان را بنویسید

دکمه بازگشت به بالا