در این مقاله پی خواهید برد که چرا ماژول‌های کد را تاکنون به سختی به اشتراک می‌گذاشتید. همه ما می‌دانیم که چگونه ورودی و خروجی ناهمزمان Node آن را به یکی از ابزارهای واقعی برای توسعه خدمات تبدیل کرده است (به طور معمول REST APIها). اگر روی پروژه‌های متوسط یا بزرگ کار کرده باشید، احتمالا روند تقسیم عملکرد بین سرویس‌های منفرد را تجربه کرده‌اید.
این روش برای کمک به گره نخوردن کد بسیار عالی است، همچنین برای استقرارهای جزئی و کاهش خطرات خرابی فاجعه بار هنگام به روزرسانی کدهای قدیمی بسیار خارق العاده است (زیرا میزان خسارتی که شما میتوانید وارد کنید محدود به یک سرویس خاص است).
همانطور که گفته شد اگر موارد فوق را تجربه کرده باشید، احتمالا با این مسئله مواجه شده‌اید که یک سری کتابخانه‌های سفارشی داخلی داشته باشید که باید بین سرویس‌های مختلف پروژه به اشتراک گذاشته شود. به عنوان مثال: فایل ورود به سیستمی که نوشتید یا آن کتابخانه ارتباطی که برای ارسال داده بین سرویس‌ها نوشتید.
در هر صورت اجبار برای به اشتراک گذاشتن کد مشترک بین ماژول‌های یک پروژه نیاز به برخی از تدارکات دارد، زیرا آنچه شما انجام نمی‌دهید این است که سه نسخه مختلف از همان کد را به طور موازی در داخل سه ماژول مختلف نگه دارید. این بدترین سناریو خواهد بود و میتوانید به راحتی از آن اجتناب کنید.
راه‌های موجود برای حل این مشکل
من مطمئنم که هرکسی می‌تواند روش‌های جایگزینی برای حل این مشکل پیدا کند، اما دو روش بسیار معمول برای انجام آن در زیر ذکر می‌کنم:
شماره 1: اشتراک کد در NPM
مطمئنا میتوانید به منظور تهیه یک پروژه جداگانه برای کد مشترک خود وقت گذاشته و آن را در NPM به اشتراک بگذارید. در نگاه اول این ممکن است ایده خوبی به نظر برسد و یک راه حل عالی باشد، در هر صورت با شرح وظایف NPM متناسب است، نه؟
با این حال اگر از دیدگاه یک قطعه کد بسیار کوچک نسبت به یک پایگاه کد بزرگتر به آن نگاه کنیم، شما نیاز دارید که آن را با دیگران تقسیم کنید، چند دلیل وجود دارد که چرا این یک روش مشکل‌ساز است. اجازه بدهید بیشتر توضیح بدهم:
- ممکن است از یک رجیستری خصوصی استفاده نکنید. به هر حال شما کد سفارشی خود را با سایر همکارانی که در حال توسعه سرویس‌های دیگر پروژه هستند به اشتراک می‌گذارید، و نمی‌خواهید دیگران در سراسر جهان از کد شما استفاده کنند (حتی کد را مشاهده کنند، چرا که می‌تواند حاوی محتوای خصوصی باشد که باید مخفی بماند). همانطور که احتمالا می‌دانید، NPM به شما امکان می‌دهد از ریپازیتوری‌های خصوصی استفاده کنید، جایی که میتوانید کد سفارشی خود را بدون انتشار آن به صورت عمومی منتشر کنید. تنظیم یک مورد به زمان و منابع نیاز دارد، بنابراین حتی اگر این یک راه حل برای آن باشد، اگر فقط چند کتابخانه سفارشی داشته باشید که بخواهید آنها را در میان ماژول‌ها به اشتراک بگذارید، مقرون به صرفه نخواهد بود.
- حتی اگر نکته قبلی برای شما مشکلی ایجاد نکرد، مجبور به استخراج کد در یک پروژه جداگانه و سپس ایجاد و انتشار ماژول‌ها هستید. توجه داشته باشید که به اشتراک گذاشتن ماژول‌ها زیاد پیچیده نیست، اما به فاکتورگیری مجدد نیاز دارد. مهم نیست که چه قدر بزرگ باشد یا برای این کار وقت یا نیروی انسانی نداشته باشید.
- کدی که استخراج کرده‌اید دیگر در دسترس شما نیست. بله این در داخل پوشه node_modules است، جایی که تعداد بسیار کمی از توسعه دهندگان جرات ورود به آن را دارند (یا حتی نمی‌دانند کجا را جستجو کنند). نکته در اینجا این است که شما به معنای واقعی کلمه کد را از پایگاه کد خود حذف کرده و آن را به یک موجودیت عمومی و خارجی تبدیل کرده‌اید. این اساسا نگهداری را دشوارتر می‌کند، زیرا اکنون یک پروژه جدید با پایگاه کد خاص خود است. این تنها درصورتی است که در مورد یک کتابخانه صحبت کنیم، اگر سه کتابخانه استخراج کنید چه می‌شود؟ یا حتی بیشتر؟ چه کسی آن را نگهداری می‌کند و چه زمانی آنها را به روزرسانی می‌کنند؟
اگرچه در نگاه اول این راه حل می‌تواند قابل قبول به نظر برسد، اما برای طولانی مدت می‌تواند دست و پا گیر و ناجور شود.
شماره 2: استفاده از GIT
دو روش وجود دارد که گیت به طور بالقوه می‌تواند در اینجا به شما کمک کند ( شاید سیستم‌های کنترل نسخه دیگر نیز همین کار را انجام دهند، اما من خیلی با آنها آشنا نیستم. بنابراین به آنچه می‌دانم پایبند خواهم ماند):
- انتقال کد عمومی به یک ریپازیتوری متفاوت، اساسا کاری مشابه آنچه با NPM انجام داده‌اید انجام می‌شود. اما اکنون باید زیرماژول‌ها را در دایرکتوری خود داشته باشید. این یک راه حل عالی است که گیت برای حل مشکلی که در مورد آن صحبت می‌کنیم ارائه می‌دهد، اما بگذارید صادقانه بگوییم این ابزار برای بسیاری از توسعه دهندگان بیش از حد شلوغ است و نیازی به اضافه کردن پیچیدگی بیشتر در رابطه با این رویکرد ندارد.
- به جای افزودن ریپازیتوری جدید، میتوانید همه چیز را به صورت انحصاری در بیاورید. بنابراین به جای اینکه سرویس‌ها و ماژول‌های خود را به ریپازیتوری‌های جداگانه تقسیم کنید، یک مورد ایجاد کرده و همه چیز را به آن اضافه می‌کنید. بسته به نوع تنظیمات می‌تواند ایده خوبی برای شما باشد، در هر صورت به آن فکر کنید. برای داشتن همه چیز در یک ریپازیتوری واحد، ارکستراسیون باید به طرز شگفت انگیزی اجرا شود. به من اعتماد کنید، من این کار را قبلا انجام داده‌ام، واقعا قابل اجرا است، اما فقط آن را به عنوان آخرین راه حل توصیه می‌کنم.
فعلا اجازه دهید گیت را از تصویر خارج کنیم، یا حداقل بگذارید آن را از راه حل بیرون بگذاریم. اگر هم قبلا برای شما کار کرده است، کاری با آن نداریم.
Bit: روشی جدید برای به اشتراک گذاشتن کامپوننت‌ها
Bit سرویس جدیدی است که به شما امکان می‌دهد کامپوننت‌ها را بین پروژه‌هایتان به اشتراک بگذارید. این در نگاه اول بسیار شبیه NPM است.
مفهوم کامپوننت‌ها اساسا هر چیزی است که می‌خواهید به اشتراک بگذارید، چه یک فایل واحد با تعریف کلاس و چه مجموعه‌ای از توابع یا یک پوشه کامل پر از کتابخانه‌های عمومی. روی هر پروژه‌ای که کار می‌کنید و ناگهان متوجه شدید قابل اشتراک گذاری است، میتوانید آن را اکسپورت کنید. پس چه تفاوتی با NPM وجود دارد؟
- اگر مبتدی هستید، دیگر کد را از پایگاه کد خود حذف نمی‌کنید. من این را یک مزیت بزرگ می‌دانم، زیرا شما بدون نیاز به جدا کردن از بقیه پروژه با محتوای به اشتراک گذاشته شده سروکار دارید. همچنان نگهدارنده آن هستید، چرا که بالاخره آن را ایجاد کرده‌اید، اما درعین حال میتوانید آن را به عنوان یک ماژول npm به اشتراک بگذارید (در عرض یک ثانیه به شما نشان خواهم داد).
- کد مشترک شما (مهم نیست که چند کامپوننت مختلف را به اشتراک می‌گذارید) در مخزن کد باقی می‌ماند. به علاوه برای اینکه بخشی از آن به اشتراک گذاشته شود، لازم نیست ارکستراسیون اضافی به راه حل نسخه سازی کد خود اضافه کنید. اگر باید مرتبا آن را به روزرسانی کنید، فقط کد را به روز می‌کنید و از ابزار CLI آخرین نسخه از پروژه مقصد را می‌گیرید.
- برخلافNPM ، Bit درخت وابستگی کامپوننت شما را بررسی می‌کند. به این معنی که اگر فقط یک فایل را به اشتراک بگذارید، اما به سایر فایل‌های محلی به عنوان وابستگی نیاز دارید، بیت به شما می‌گوید و به شما امکان می‌دهد آنها را به عنوان بخشی از کامپوننت اضافه کنید.
اساسا Bit به شما امکان می‌دهد با رویکردی مشابه با شماره 1 مشکل را حل کنید، همچنین منابعی را برای شما فراهم می‌کند تا آن را درست انجام دهید:
- رجیستری خصوصی توسط Bit ارائه می‌شود، بنابراین لازم نیست نگران آن قسمت باشید.
- برای انتشار نیازی به تنظیم ماژول npm جدید ندارید، فقط با چند مرحله میتوانید بدون نیاز به انجام هر نوع بازسازی مجدد، کد را به اشتراک بگذارید.
- کد را از پروژه اصلی که در آن منشا گرفته استخراج نمی‌کنید. بلکه در همان مکان و در داخل همان ریپازیتوری باقی می‌ماند و تأثیر آن بر روی پروژه تقریبا هیچ است.
استفاده از Bit برای به اشتراک گذاشتن کامپوننت‌ها
چگونه کد خود را به اشتراک بگذاریم؟ آنها مستندات بسیار دقیقی دارند که در آن میتوانید جزئیات بیشتری را بررسی کنید، اما برای سادگی به شما نشان می‌دهم که چگونه سریعا یک کامپوننت را از یک پروژه به پروژه دیگر به اشتراک بگذارید.
کامپوننتی که می‌خواهیم به اشتراک بگذاریم یک شی logger است که نمونه‌ای از Winston می‌باشد:
const winston = require("winston")
const config = require("../config.json")
const logger = winston.createLogger({
level: 'info',
format: winston.format.json(),
transports: [
new winston.transports.File({ filename: config.logging.output_files.error, level: 'error' })
]
});
if (process.env.NODE_ENV !== 'production') {
logger.add(new winston.transports.Console({
format: winston.format.simple()
}));
}
module.exports = loggerگام اول: Bit را نصب کنید
میتوانید آن را به روش‌های مختلف نصب کنید، اما ساده‌ترین و عمومی‌ترین استفاده از npm است:
$ npm install bit-bin --globalگام دوم: ورود به سیستم
پس از نصب باید وارد شوید یا ثبت نام کنید. انجام این کار بسیار ساده است، به خصوص اگر قبلا یک حساب Github داشته باشید. از خط فرمان فقط کافی است تایپ کنید:
$ bit loginاین دستور مرورگر شما را راه اندازی کرده و صفحه ورود به سیستم Bit را باز می‌کند. پس از ورود به آنجا و انجام اقدامات ثبت نام / ورود به سیستم میتوانید تنظیم کنید که چه مواردی را به اشتراک بگذارید.
همچنین توجه داشته باشید که با ورود به سیستم، دامنه جدیدی را به فایل پیکربندی NPM اضافه می‌کنید. اکنون به دامنه bit دسترسی خواهید داشت که به شما امکان می‌دهد کامپوننت‌های سازنده را مانند ماژول‌های کلاسیک NPM نصب کنید.
گام سوم: مقداردهی اولیه Workspace
بیت از مفهوم workspace برای گروه بندی مجموعه‌ها (گروهی از کامپوننت‌ها هستند) استفاده می‌کند. اولین کاری که باید انجام دهید این است که فضای کاری خود را مقداردهی کنید و میتوانید این کار را به سادگی انجام دهید:
$ bit initپس از اتمام این میتوانید تصمیم بگیرید که چه چیزی را به اشتراک بگذارید.
گام چهارم: یک کامپایلر را پیکربندی کنید
Bit کامپایلرهای از پیش پیکربندی شده مختلفی را برای کامپوننت های تحت مدیریت فضای کاری ارائه می‌دهد. ما از Babel compiler component استفاده خواهیم کرد. این به ما امکان می‌دهد بدون تکیه بر تنظیمات خاصی در محیط، کدی قابل توزیع برای کامپوننت "logger" خود ایجاد کنیم.
کامپوننت ما به لطف کامپایلر Babel استاندارد شده در جاهای دیگر به راحتی توسط دیگران قابل نگهداری است.
$ bit import bit.envs/compilers/babel --compilerگام پنجم: افزودن فایل و بررسی وضعیت کامپوننت‌ها
افزودن فایل‌هایی که می‌خواهید به اشتراک بگذارید کاملا ساده است. با فرض یک ساختار پروژه مانند موارد زیر:
برای اضافه کردن فایل‌ها میتوانید به سادگی آن را انجام دهید:
$ bit add lib/logger.jsاین دستور فایل را اضافه کرده و یک کامپوننت جدید به نام "logger" ایجاد می‌کند. به طور پیش فرض دستور add با استفاده از نام فایل، کامپوننت را نام گذاری می‌کند. همچنین میتوانید مستندات کامل آن را بررسی کنید تا همه کارهایی که میتوانید با آن انجام دهید را مشاهده کنید.
اکنون میتوانید وضعیت را بررسی کنید تا بفهمید که آیا همه موارد مورد نیاز خود را دارید:
$ bit status
تصویر بالا خروجی بررسی‌های انجام شده توسط Bit را به شما نشان می‌دهد. اینجاست که CLI درخت وابستگی ماژول ما را ایجاد و بررسی می‌کند. اگر از قبل به کد نگاه کنید، متوجه خواهید شد که من به یک فایل JSON احتیاج دارم که هنوز اضافه نکرده‌ام. این یکی از مزایای استفاده از Bit به جای npm است، چرا که می‌توانیم از دست دادن فایل‌های مهم جلوگیری کنیم.
پس از افزودن فایل دیگر میتوانید وضعیت جدیدی را بررسی کنید و پاسخ ظاهری بهتری خواهید گرفت.
گام ششم: نسخه بندی
قبل از بارگذاری فایل‌ها باید نسخه کامپوننت را مشخص کنید. بنابراین یک روش عالی برای مقادیر اولیه همه آنها به طور همزمان است:
$ bit tag --all 0.0.1 --message "initial version for the component"این مرحله اجباری است و تا زمانی که نسخه اول را تگ نکنید، قادر به کامیت کردن چیز دیگری نخواهید بود.
گام هفتم: اکسپورت کردن کامپوننت
وقتی همه موارد بالا آماده شد، برای اکسپورت کامپوننت‌های سازنده لازم است مجموعه‌ای را که قرار است در آن جای بگیرند، ایجاد کنید. شما این کار را از وبسایت آنها انجام میدهید و پس از ایجاد آن میتوانید دستور زیر را اجرا کنید:
$ bit export <account-name>.<collection-name>من مجموعه را "custom-logger" نامیدم و نام حساب من "deleteman" است، بنابراین دستور من اینگونه خواهد بود:
$ bit export deleteman.custom-loggerبا این کار فایل بدون اینکه کاری برای کد شما و یا ریپازیتوری شما انجام شود، در رجیستری سفارشی بارگذاری می‌گردد.
گام هشتم: استفاده از آن در مکان دیگر (اختیاری)
اگر لازم باشد از کامپوننت خود در پروژه دیگری استفاده کنید، چه کار می‌کنید؟ میتوانید از دستور زیر استفاده کنید:
$ npm install @bit/<account-name>.<collection-name>.<component-name>بنابراین برای من اینگونه خواهد بود:
$ npm install @bit/deleteman.custom-logger.loggerاگر من به یکی از کامپوننت‌ها مراجعه کنم، همه وابستگی‌ها نیز نصب می‌شوند. بنابراین برای استفاده از آن، فقط کافی است به این صورت عمل کنید:
const logger = require("@bit/deleteman.custom-logger.logger")
logger.info("Testing test!")جمع بندی
با استفاده از این مراحل ساده، شما موفق شده‌اید کدی را از پروژه خود به اشتراک بگذارید، بدون اینکه مجبور شوید آن را استخراج کنید.
به خاطر اینکه مقاله زیاد طولانی نشود، تصمیم گرفتم مراحل اضافی را کنار بگذارم (مانند اینکه چگونه تعامل بین Git و Bit نشان داده می‌شود، یا اینکه چگونه محتوای یک کامپوننت و نسخه آن را به روز کنید). در پشت این مراحل اساسی چیزهای بیشتری وجود دارد، اما امیدوارم این کافی بوده باشد تا مزایای استفاده از چنین خدماتی را برای به اشتراک گذاشتن کد بین پروژه‌های مرتبط با حداقل تلاش به شما نشان دهد.
اگر قبلا از Bit استفاده کرده‌اید یا اگر با رویکرد دیگری توانسته‌اید این مشکل را حل کنید، نظرات خود را در زیر بنویسید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید