
المشاركة الأصلية باللغة الروسية
الحفاظ على التعليمات البرمجية الخاصة بك متسقة وجيدة التنسيق ليست مهمة سهلة حتى عندما تعمل بمفردك. ولكن عندما تعمل مع فريق أو مع مشروع مفتوح المصدر ، يصبح كل شيء أكثر صعوبة. لكل شخص نمط رمز خاص به ، ولا يقوم شخص ما بإجراء اختبارات ، ولا أحد يكتب الوثائق. ستساعدك هذه المقالة على إعداد كل هذه الأشياء وحتى أكثر - أتمتة هذا الروتين لعدم القيام بذلك يدويًا.
بعد القراءة ، ستحصل على مشروع جاهز لآلية npm مع الميزات التالية:
- تنسيق النص ونمط الرمز
- الاختبارات الآلية مع تغطية الشفرة والعتبة
- نمط الالتزام الموحد
- الوثائق الناتجة من الكود والالتزامات
- عملية النشر الآلي
دعنا نذهب!
المتطلبات الأساسية
إنشاء مجلد جديد ، تهيئة مستودع جديد ، مشروع والانتقال إلى الخطوة التالية.
git init npm init npm i -D typescript ./node_modules/.bin/tsc --init
لنبدأ بتنسيق التعليمات البرمجية - أنواع المسافة البادئة والحجم وما إلى ذلك. الأداة الأولى هي. editorconfig ملف. لا يتطلب أي شيء ما عدا IDE الخاص بك ويساعد على الحفاظ على التنسيق التلقائي الخاص بك متسقًا في جميع أعضاء فريقك.
قم بتكوين .editorconfig في جذر المشروع مع المحتوى التالي (لا تتردد في تغييره للأسلوب الذي تريده)
#root = true [*] indent_style = space end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true max_line_length = 100 indent_size = 4 [*.md] trim_trailing_whitespace = false
هذا رائع حقًا ، لكن في بعض الأحيان لا تملك القوة الكافية لتلبية احتياجاتك. لضمان أن كل شيء جيد التنسيق يظهر. إذا نسيت تنسيق الكود ، فستفعله أجمل لك.
npm i -D prettier
أضف هذا الأمر إلى قسم البرامج النصية ملف package.json الخاص بك
"prettier": "prettier --config .prettierrc.json --write src/**/*.ts"
وقم بإضافة ملف .prettierrc.json مع إعداداتك إلى جذر المشروع
{ "tabWidth": 4, "useTabs": false, "semi": true, "singleQuote": true, "trailingComma": "es5", "arrowParens": "always" }
الآن يمكنك كتابة بعض التعليمات البرمجية ومحاولة تشغيل "تشغيل npm أجمل". سوف أجمل تحقق مجلد src وتنسيق التعليمات البرمجية تلقائيا دون أي مساعدة من جانبكم!
رمز النمط
نمط الشفرة - مثل تجنب استخدام == بدلاً من === أو متغيرات التظليل تحتاج أيضًا إلى التحقق. لهذا الغرض ، سنتخذ tslint . إذا كنت تفضل javascript - خذ eslint بدلاً من ذلك.
npm i -D tslint ./node_modules/.bin/tslint --init
سيقوم الأمر الأخير بإنشاء ملف tslint.json لك. يحتفظ بإعداداتك ويقوم بالفعل بتوسيع tslint: مجموعة القواعد الموصى بها ، ولكن يمكنك توسيعها أو تجاوزها ما تريد. لا تنسَ إضافة أمر الوبر إلى package.json.
package.json
"lint": "tslint -c tslint.json 'src/**/*.ts' 'tests/**/*.spec.ts'"
كما تراه الإعداد للعمل مع src و مجلد الاختبارات ، لذلك يجب وضع كل التعليمات البرمجية هناك.
اختبار
الآن حان الوقت لإعداد اختباراتنا. تثبيت الكرمة والتبعيات الأخرى ذات الصلة
npm i -D karma karma-jasmine jasmine karma-typescript karma-chrome-launcher @types/jasmine ./node_modules/.bin/karma init
وإضافة كتلة التكوين الجديدة إلى karma.conf.js المنشأ حديثا
karma.conf.js karmaTypescriptConfig : { include: ["./src/**/*.ts", "./tests/**/*.spec.ts"], tsconfig: "./tsconfig.json", reports: { "html": "coverage", "lcovonly": { directory: './coverage', filename: '../lcov.dat' } }, coverageOptions: { threshold: { global: { statements: 60, branches: 60, functions: 60, lines: 60 }, file: { statements: 60, branches: 60, functions: 60, lines: 60, } } }, }
سيؤدي هذا إلى إعداد ملف تغطية التعليمات البرمجية ومستوى العتبة. كلاهما مهم. أول واحد يساعدك على التعامل مع تغطيتك والثانية تبقي تغطيتك على مستوى معين.
تحديث package.json
"test": "karma start"
وحاول تشغيله. لا تنس أن تكتب بعض التعليمات البرمجية داخل مجلد src والاختبارات داخل مجلد الاختبارات. هذه هي الطريقة التي سيبدو بها تقرير تغطية الشفرة:

راجع للشغل ، إذا كنت تخطط لاستخدام تكامل مستمر (مثل Travis أو Jenkins أو ما إلى ذلك) ، فمن الأفضل تغيير عداء Chrome إلى HeadlessChrome مع دمية . لمزيد من المعلومات حول HeadlessChrome و CI - تحقق من مستودع العرض التوضيحي الخاص بي على GitHub.
أسلوب الالتزام
عادةً ما يرتكب كل الكتابة بتنسيق "عشوائي". لذلك ، للحفاظ على ارتكابها جيدة بما فيه الكفاية ، اخترع المواطن . هذه الأداة تطرح بعض الأسئلة وتوليد الالتزام بالنسبة لك. نقطة أخرى جيدة أننا يمكن أن إنشاء ملف سجل التغيير من الالتزامات المكتوبة بمساعدة المواطن.
تثبيت محول مبدل و changelog التقليدية
npm i -D commitizen npm i -D cz-conventional-changelog
تحديث البرامج النصية
"commit":"git-cz"
إضافة قسم التكوين الجديد داخل package.json للمواطن.
"config": { "commitizen": { "path": "./node_modules/cz-conventional-changelog" } }
حاول أن تلتزم أو تحقق من هذه الصورة للحصول على فكرة كيف ستبدو:

الوثائق
إذا كان مشروعك أكبر من عدد قليل من الوظائف ، فمن المستحسن الحصول على بعض الوثائق. والأفضل أنه عندما لا تحتاج إلى كتابة شيء يدويًا. لهذه الأغراض typedoc موجود. يستغرق ملفاتك .ts ، jsdoc تعليقاتك ويخلق وثائق جميلة ولامعة. إذا كنت تستخدم JavaScript - يمكنك تجربة esdoc بدلاً من ذلك.
في ما يلي مثال على ذلك ، كيف وصفت typedoc وظيفتي هي NumberStrict:

npm i -D typedoc
package.json
"doc": "typedoc --out docs/src"
فكرة أخرى جيدة هي جعل ملف سجل التغيير الخاص بك يتم إنشاؤه تلقائيًا أيضًا. كما ذكرت من قبل ، المواطن يدعم التغيير التقليدي. لذلك ، يمكننا أن نلتزم ونحولها إلى ملف سجل التغيير.
تثبيت التقليدية سجل التغيير
npm i -D conventional-changelog-cli
وتحديث package.json مع الأمر الجديد
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
لا تقلق ، الزاوي يعني فقط تنسيق الأسلوب وليس أكثر. الآن ، سيتم تشكيل سجل التغيير الخاص بك مثل رفع الصوت عاليا:

بناء
البنية بسيطة للغاية وهي مجرد إضافة أوامر بناء وتنظيف إلى package.json
"clean":"rmdir dist /S /Q", "build": "tsc --p ./ --sourceMap false",
إذا كنت بحاجة إلى تجميع أو تصغير - جرب uglifyjs .
الأتمتة
حسنا ، الجزء الأكبر القيام به بالفعل. أنشأنا مجموعة من البرامج النصية المختلفة للحفاظ على كودنا نظيفًا وصحيحًا. لكن تشغيلها في كل مرة يدويًا هي مهمة مملة جدًا ويمكن أن تؤدي إلى أخطاء. لذلك ، نحن بحاجة إلى أتمتة لهم. كما تعلم ، عند إجراء التزام ، تظهر بعض أحداث git - pre-pre-post-post وما إلى ذلك. يمكننا استخدامها لتشغيل البرامج النصية الخاصة بنا قبل الالتزام بالكود أو دفعه. ولكن هناك مشكلة - السنانير بوابة ليست قابلة للمشاركة. ولهذا السبب يبدو أجش . تغلف هذه الحزمة أحداث git وتقوم بتشغيل البرامج النصية الخاصة بك من package.json. إذا فشل البرنامج النصي ، فسيتم إلغاء الالتزام وستصلك رسالة عما يحدث.
تثبيت أجش
npm i -D husky
ووصف بعض السنانير داخل package.json
"precommit":"npm run prettier", "prepush": "call npm run lint && call npm run test"
الآن ، عند محاولة جعل أجمل الالتزام سيتم تشغيل وإصلاح جميع مشاكل التنسيق. عند محاولة إجراء رمز الدفع والاختبارات سيتم تلقائيًا. يمكنك تمديد هذه الأوامر كل ما تحتاج إليه مثل إرسال الإشعارات والتحقق الإضافي إلخ.
نشر
عظيم ، لقد انتهينا تقريبا. لذلك ، لنفترض أننا مستعدون لنشر الحزمة إلى npm. كما تعلمون ، يجب القيام بالكثير من العمل من قبل - الاختبارات ، تحديث الوثائق ، إصدار ، وتحديث العلامات. من السهل أن ننسى شيئا ، نعم؟ لذلك ، إنها لفكرة جيدة لأتمتة هذه العملية أيضًا. لهذه الأغراض ، سوف نستخدم روابط npm أصلية - preversion ، والإصدار ، و postversion. أضف الأسطر التالية إلى قسم البرامج النصية الخاصة بك package.json
"preversion": "npm run test", "version": "call npm run clean && call npm run build && call npm run doc && call npm run changelog && git add . && git commit -m 'changelogupdate' --no-verify", "postversion": "git add . && git push && git push --tags"
عندما تقوم بتشغيل الأمر npm version ، سيقوم البرنامج النصي preversion بإجراء الاختبارات ، وسيقوم البرنامج النصي لإصدار التعليمات البرمجية الخاصة بك وإنشاء جميع المستندات. ثم سيتم زيادة الإصدار وبعد ذلك سيتم الالتزام بها وطردها. الآن كل ما تحتاجه هو تشغيل الأمر npm publish وهذا كل شيء. فقط للأوامر وسيتم كل شيء آخر دون أي جهد من جانبكم.
أخيرًا ، نحتاج إلى تحديد المجلدات التي يجب تضمينها في المشروع وأين يمكن تحديد موقع نقطة الدخول. تحديث package.json آخر مرة
"main": "./dist/index.min.js", "types": "./dist/index.d.ts", "files": [ "dist/", "src/", "tests/" ]
هذا كل شيء ، مشروعك الرائع جاهز للذهاب!
روابط مفيدة
شكرا للقراءة. إذا كان لديك أي أسئلة ، فالرجاء التحقق من مستودع العرض التوضيحي الخاص بي هنا أو طرح التعليقات.
أتمنى لك يومًا سعيدًا!