بررسی ابزار بان Bun برای کمک به توسعه دهندگان جاوا اسکریپت و تایپ اسکریپت

به نظر می رسد هر چند سال یک بار، یک ابزار جاوا اسکریپت جدید همه را قبل از اینکه هیاهو آرام شود، هیجان زده می کند. این بار نوبت بون است. Bun راه حل متفاوتی برای کمک به توسعه دهندگان جاوا اسکریپت و تایپ اسکریپت است، اما آیا به همان اندازه که توییت ها نشان می دهند انقلابی است؟ بیا یک نگاهی بیندازیم!

ابزار جاوا اسکریپت

فرقی نمیکند که یک توسعه‌دهنده فول استک، بک‌اند یا فرانت‌اند باشید، احتمالا Node.js و NPM شما را تحت تأثیر قرار داده‌اند. اگرچه Node.js یک پلت فرم عالی برای ساخت جاوا اسکریپت سمت سرور است، اما به نظر من، مزیت واقعی همه آن اکوسیستم غنی ابزار است که من به آن عادت کرده ام. این شامل مواردی مانند Gulp، Vite، TailwindCSS، و غیره می‌شود. برای توسعه سمت کلاینت، به سختی می‌توانید پروژه‌ای را پیدا کنید که از نوعی ابزار مبتنی بر Node.js استفاده نمی‌کند.

برای بسیاری از ما، این خوب است. اما مگس در پماد وجود دارد. اول از همه، سیستم مدیریت بسته و اکوسیستم درخشان هستند. اما خود npm می تواند در نصب و مدیریت بسته ها کند باشد. به همین دلیل است که جایگزین هایی مانند yarn و pnpm وجود داشته است. این پروژه ها برای بهبود پروژه بود. از آنجا که آنها اساساً با نحوه عملکرد npm (حداقل در سطح) یکسان هستند، برای بهبود عملکرد نصب و مدیریت بسته ها بسیار عالی بوده اند.

در قسمت سرور، Node.js کمی طولانی شده است. Node.js برای انتقال به ماژول های ECMAScript که ممکن است برخی ترجیح دهند کندتر بوده است. و برخی از مشکلات عملکرد وجود دارد. برای اکثر کاربران، Node.js بسیار سریع است، اما برای برخی، آنها چیزی سریعتر می خواستند. Deno به عنوان یک زمان اجرا جدید برای پروژه های Node.js ایجاد شد. اگرچه آن نوع پذیرشی که برخی پیش‌بینی می‌کردند نداشته است، اما همچنان نشان‌دهنده جهتی است که جامعه به سمت آن می‌رفت. بر روی سازگاری با اجرای کارآمدتر در زمان اجرا متمرکز شد.

برای توسعه سمت کلاینت، یکی از مقوله‌هایی که بسیار مهم بوده، راه‌هایی برای کارآمدتر کردن جاوا اسکریپت برای مرورگر است. این ابزارها شامل ترانسپایلرها و باندلرها هستند. پروژه‌هایی مانند Webpack، Rollup، Browserify و دیگران، هدفشان پردازش جاوا اسکریپت (یا TypeScript) به بسته‌های کارآمد برای پروژه‌های مبتنی بر وب است. دلایل اولیه این امر این بود که به توسعه دهندگان وب اجازه می داد از نسخه های بعدی جاوا اسکریپت در حین کامپایل کردن نسخه های قبلی که در مرورگر پشتیبانی می شدند، استفاده کنند. این ابزارها همچنین پروژه‌های جاوا اسکریپت را به تمام کدهایی که واقعاً استفاده می‌شوند تقسیم می‌کنند (مثلاً تکان دادن درخت)، کد را کوچک می‌کنند، و کد را به ماژول‌هایی که با تنبلی بارگذاری می‌شوند، تقسیم می‌کنند. اینها به طرز چشمگیری موفق بوده اند. آنها روش استقرار پروژه های وب را تغییر داده اند.

با در نظر گرفتن همه این موارد، چرا Bun ایجاد شد؟

Bun چیست؟

هدف ابزار Bun ایجاد ابزاری برای مدیریت چهار سناریو اصلی برای ابزارسازی جاوا اسکریپت است:

  • زمان اجرای جاوا اسکریپت
  • مدیریت بسته
  • باندلر
  • اجرای تست

اهداف اعلام شده از زمان اجرا جدید عبارتند از:

  • سرعت
  • TypeScript و JSX/TSX را بدون نیاز به ترانسپایل کردن آنها اجرا کنید
  • سازگاری ESM و CommonJS
  • APIهای مرورگر وب پخته شده، مانند واکشی و سوکت‌های وب
  • سازگاری کامل Node.js/NPM

Bun ادعا می کند که چهار برابر سریعتر از Node.js است. برای پروژه های سمت سرور مانند Node.js، رندر سمت سرور و ابزارسازی، این سرعت تمام بخش های فرآیند توسعه را بهبود می بخشد. اینکه بتوانید به همان کد خود (با سازگاری Node.js) تکیه کنید و چهار برابر افزایش سرعت داشته باشید ادعای بزرگی است.

اگر همه اینها درست باشد، می توانید متوجه شوید که چرا Bun در زمان انتشار این همه تبلیغات شده است. تجربه من (عمدتاً توسعه سمت مشتری) این است که ابزارها مطابق تبلیغات تبلیغاتی هستند. برای روشن شدن، این یک نسخه ۱.۰ است. مطمئن نیستم هر کاری که انجام می‌دهم را به Bun منتقل کنم تا زمانی که برخی از کاربران اولیه کمک کنند تا لبه‌های ناهموار را پایین بیاورند. اما اگر می خواهید دستتان را کثیف کنید، بیایید آن را نصب کنیم.

نصب Bun

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

در نسخه ۱.x، Bun از ویندوز پشتیبانی نمی کند. WSL به شما فرصتی می دهد تا آن را امتحان کنید.

در عوض، می‌توانید با استفاده از زیرسیستم ویندوز برای لینوکس (WSL) نگاهی به نحوه عملکرد آن بیندازید. دستورالعمل نصب در اینجا برای Linux/Mac/WSL است. آنها باید یکسان باشند. برای شروع، یک کنسول باز کنید. برای استفاده از نصب کننده، باید unzip را نصب کرده باشید. می توانید شروع کنید؛ فقط unzip را نصب کنید:

$ sudo apt-get install unzip

پس از نصب، می توانید آن را با curl نصب کنید:

$ curl https://bun.sh/install | bash

خودشه. با استفاده از:

$ bun -v 
۱.۰.۷

اگر می توانید نسخه را ببینید، همه چیز آماده است. بیایید ببینیم چگونه می توانید از Bun استفاده کنید.

استفاده از Bun

اکنون که Bun را نصب کرده اید، می خواهید از آن برای کار استفاده کنید. بیایید یک مثال را مرور کنیم.

ایجاد یک پروژه

Bun برای ایجاد یک پروژه جدید به چیز خاصی نیاز ندارد. معادل npm init به نام bun create دارد :

$ bun create astro

کاری که واقعا انجام می دهد این است که سعی می کند تماس بگیرد:

$ bunx create-astro

دستور bux معادل npx از npm است. این بدان معناست که bun create اکثر سیستم‌های پروژه ایجاد را که قبلاً با npm و yarn استفاده می‌شوند، می‌پذیرد. این بدان معنی است که شما می توانید انواع پروژه های معمولی ایجاد کنید، مانند:

$ bun create vue
$ bun create react-app
$ bun create svelte
$ bun create astro

برای روشن بودن، این به اندازه ای نیست که Bun از این فریمورک ها پشتیبانی می کند، بلکه در عوض، در مورد آن چیزی است که شما از قبل انجام می دهید. برای استفاده از Bun لازم نیست پروژه های خود را با Bun ایجاد کنید. در ادامه این مقاله نحوه استفاده از آن را با پروژه های موجود خواهید دید.

برای استفاده از Bun لازم نیست پروژه های خود را با Bun ایجاد کنید.

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

یکی از جاهایی که می بینم از Bun زیاد استفاده می کنم، مدیریت وابستگی هاست. سرعت آن باعث می شود که برای پروژه های بزرگتر واقعا قانع کننده باشد. اگرچه این یک مورد یکبار مصرف برای بسیاری از موارد است، من می توانم ببینم که از آن در سرورهای CI برای بهبود عملکرد ساخت استفاده می شود. به عنوان مثال، برای یک برنامه استاندارد Vue، می‌توانید فقط از bun install (یا فقط bun i ) استفاده کنید:

$ bun install
bun install v1 (b0393fba)
 + @tsconfig/node18@۱۸.۲
 + @types/jsdom@۲۱.۱
 + @types/node@۱۸.۱۸ (v20 available)
 + @vitejs/plugin-vue@۴.۴
 + @vitejs/plugin-vue-jsx@۳.۰
 + @vue/test-utils@۲.۴
 + @vue/tsconfig@۰.۴
 + jsdom@۲۲.۱
 + npm-run-all2@۶.۱
 + typescript@۵.۲
 + vite@۴.۵
 + vitest@۰.۳۴
 + vue-tsc@۱.۸.۲۱
 + pinia@۲.۱
 + vue@۳.۳
 + vue-router@۴.۲

من به خصوص دوست دارم که نشان دهد (به روشی مختصر) چه بسته هایی نصب شده اند (و همچنین آیا نسخه های جدیدتر در دسترس هستند). به جای فایل قفل بسته ای که npm ایجاد می کند، فرمت قفل خاص خود را دارد، همانطور که در شکل ۱ نشان داده شده است .

شکل ۱: فایل قفل Bun

این رفتار با نحوه کار نخ و npm یکسان است. شما می توانید یک بسته جدید مانند این نصب کنید:

$ bun i tailwindcss autoprefixer postcss
bun add v1.۰.۷ (b0393fba)
   installed tailwindcss@۳.۳.۵ with binaries:
      - tailwind
      - tailwindcss
   installed autoprefixer@۱۰.۴.۱۶ with binaries:
      - autoprefixer
   installed postcss@۸.۴.۳۱
 ۶۸ packages installed

نکته ای که باید به آن توجه داشت این است که رفتار نصب برای سازگاری با npm است. در Bun معمولاً از bun add (یا فقط یک ) استفاده می کنید :

$ bun add tailwindcss autoprefixer postcss
$ bun a tailwindcss autoprefixer postcss

من دوست دارم که آنها این فرآیندها را به دو دستور فرعی با نام تفکیک کرده اند.

برای حذف یک بسته، می توانید از دستور bun remove (یا bun rm ) استفاده کنید:

$ bun remove postcss
$ bun rm postcss

و برای به روز رسانی بسته یا بسته ها، دستور bun update :

$ bun update
$ bun update tailwindcss

می توانید پروژه یا بسته های فردی را به روز کنید. توجه داشته باشید که bun update و bun upgrade دستورات کاملا متفاوتی هستند. دستور ارتقاء bun به طور خاص در مورد ارتقاء خود Bun است.

در حال توسعه با Bun

هنگام کار با Bun، این زمان اجراست که می تواند بسیار مفید باشد. مانند npm، bun می‌تواند از اسکریپت‌ها در package.jsonفایل شما استفاده کند و به شما امکان می‌دهد به سادگی اسکریپت dev را اجرا کنید:

$ bun run dev

در ظاهر، باید به همین سادگی باشد. اما برای برخی از انواع پروژه، حداقل در حال حاضر، باید ابزار را مجبور به استفاده از bun کنید . به عنوان مثال، هر پروژه ای که از Vite برای توسعه استفاده می کند، باید از bunx استفاده کند تا Vite از زمان اجرای JS Bun استفاده کند. می توانید این کار را با افزودن پرچم –bun انجام دهید .

$ bunx --bun vite

من معمولا فقط این را در اسکریپت های package.json پنهان می کنم:

{
    "name": "bun-oven",
    "version": "۰.۰.۰",
    "private": true,
    "scripts": {
        "dev": "bunx --bun vite",
...

اگرچه به دلیل اجرای بهتر Bun، انجام این کار مزیت عملکردی دارد، با برخی از ابزارهایی که در حال حاضر بسیار سریع هستند (مثلاً Vite)، تفاوت قابل توجه نیست. البته، با افزایش مقیاس، این واقعاً قابل مشاهده است. به عنوان مثال، در یک پروژه بزرگ Next یا Nuxt، زمان اجرای سریعتر باید واقعاً آشکار باشد. اما در برنامه hello world Vue ، هرگز تفاوت را متوجه نخواهید شد.

در حال اجرا تست ها

ضرر برخی از توسعه دهندگان فرانت اند سرعت دوندگان آزمایشی است. اشتباه نکنید، دوندگان آزمون در حال انجام کارهای زیادی برای یافتن و اجرای تست های شما هستند. این یکی از زمینه‌هایی است که Bun می‌خواهد آن را بهبود بخشد. برای انجام این کار، آنها یک تست رانر را مستقیماً در ابزار پیاده سازی کردند.

در خارج از جعبه، Bun می تواند تست هایی را اجرا کند که از تست های سبک شوخی استفاده می کنند. به عنوان مثال، یک آزمایش ساده ممکن است:

const counter = require('./counter');
describe("simple tests", () => {
    test('test increment', () => {
        const beforeCount = counter.count;
        counter.increment()
        expect(counter.count)
            .toBe(beforeCount + ۱);
    });
    test('test double', () => {
        counter.increment()
        expect(counter.doubleCount())
            .toBe(counter.count * ۲);
    });
});

تست کردن این مورد با jest به سادگی فراخوانی jest است:

$ jest

با Bun، فقط می توانید از تست bun استفاده کنید . هیچ وابستگی لازم نیست:

$ bun test

در آزمایش من، تست bun به طور قابل توجهی سریعتر بود:

> jest
 PASS  ./counter.test.js (۵.۵۶۸ s)
  simple tests
    ? test increment (۶ ms)
    ? test double
Test Suites: ۱ passed, ۱ total
Tests:       2 passed, ۲ total
Snapshots:   ۰ total
Time:        ۶.۶۲۴ s
Ran all test suites.

در مقایسه با:

bun test v1.۰.۷ (b0393fba)
counter.test.js:
? simple tests > test increment [۰.۰۳ms]
? simple tests > test double [۰.۰۲ms]
 ۲ pass
 ۰ fail
 ۲ expect() calls
Ran ۲ tests across ۱ files. [۳۰.۰۰ms]

این زمان‌ها کاملاً ثابت بودند، اگرچه من اینها را در WSL و در درایو ویندوز اجرا می‌کنم که می‌تواند اعداد را تغییر دهد. من انتظار دارم که تفاوت بیشتر به کشف و سرعت اجرا باشد. با تعداد زیادی آزمایش، بهبود زمان راه اندازی و کشف احتمالاً برای اجرای کلی آزمایش ها اهمیت کمتری خواهد داشت.

آیا آماده است؟

این سوال بزرگ است. این مقاله با نسخه ۱.۰.۷ نوشته شده است، بنابراین هنوز نسخه اولیه منتشر شده است. من کنجکاو هستم که آنها چقدر برای رسیدن به یک نسخه ویندوز قابل اعتماد جدی هستند.

در آزمایش من، Bun هنوز برخی مشکلات سازگاری عمده با پروژه های موجود دارد. برای جاوا اسکریپت ساده، بسیار بی عیب و نقص کار می کرد. اما Vite، Vue، React، Next یا Nuxt را معرفی کنید و مشکلات خیلی سریع ظاهر می شوند. به عنوان مثال، وقتی سعی کردم تست هایی را در داخل یک پروژه Vue بنویسم، خطاهایی را ایجاد کرد که به نظر می رسید مانند دو هفته پیش جدید باشد.

توصیه من این است که ارزش این را دارد که به آن توجه کنید. برای اکثر توسعه دهندگان، تبلیغات بیش از آنچه باید باشد. من مشتاقانه منتظر انتشار قابل توجهی هستم که در آن زمان شروع به استفاده از آن کنم. اگر در حال حاضر از ابزارهای دیگری استفاده می کنید (به عنوان مثال، تست Yarn، pnpm یا غیر Jest)، مزایای آن در حال حاضر عالی نیستند.

ما کجا هستیم؟

برخی از جهت‌گیری‌ها می‌تواند تجربه توسعه را بهبود بخشد. بهبود در زمان اجرا ممکن است مزیت واقعی باشد، به خصوص برای جاوا اسکریپت سمت سرور. اما برای توسعه‌دهندگان فرانت‌اند، فعلاً صبر می‌کنم. حتی بهبودهای مدیریت وابستگی (مثلاً نصب bun ) به اندازه کافی برای من موفقیت بزرگی نیست که بتوانم آن را به همه توصیه کنم.

کد منبع

کد منبع این مقاله را می توانید در https://github.com/shawnwildermuth/bun-getting-started دانلود کنید

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

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *