توجد طرق سهلة لتكوين TypeScript لتسريع الترجمة والتحرير. وكلما تم تنفيذها بشكل أسرع ، كان ذلك أفضل. هناك أيضًا بعض الأساليب الشائعة للتحقيق في أسباب بطء الترجمة والتحرير ، وبعض الإصلاحات والطرق الشائعة لمساعدة فريق TypeScript في استكشاف المشكلات وإصلاحها.

1. كتابة تعليمات برمجية سهلة التجميع

1.1. تفضيل الواجهات على التقاطعات (التقاطع)

في كثير من الأحيان ، يعمل الاسم المستعار البسيط لنوع الكائن بنفس طريقة الواجهة.

interface Foo { prop: string }

type Bar = { prop: string };

ولكن إذا كنت بحاجة إلى مزيج من نوعين أو أكثر ، فيمكنك إما توسيعهما باستخدام واجهة أو إنشاء تقاطع للأنواع داخل اسم مستعار. الفرق بين هذه الأساليب مهم.

تقوم الواجهات بإنشاء نوع كائن واحد مسطح يعرض تعارضات الملكية التي عادة ما تكون مهمة لحلها! وتجمع التقاطعات الخصائص بشكل متكرر ، وفي بعض الحالات تولد never

. أيضًا ، يتم تقديم الواجهات بشكل أفضل ، بينما لا يمكن عرض الأسماء المستعارة لكتابة التقاطعات في التقاطعات الأخرى. يتم تخزين علاقات النوع بين الواجهات مؤقتًا ، على عكس أنواع التقاطع. الاختلاف المهم الأخير هو أنه عند التحقق من نوع التقاطع المستهدف ، يتم التحقق من صحة كل مكون قبل التحقق من صحته / تسويته.

لذلك ، يوصى بتوسيع الأنواع باستخدام interface

/ extends

بدلاً من إنشاء تقاطعات من النوع.

- type Foo = Bar & Baz & {
-     someProp: string;
- }
+ interface Foo extends Bar, Baz {
+     someProp: string;
+ }

1.2 استخدام كتابة التعليقات التوضيحية

يمكن أن تؤدي إضافة التعليقات التوضيحية للنوع ، خاصة لقيم الإرجاع ، إلى توفير الكثير من العمل للمجمع. ويرجع ذلك جزئيًا إلى أن الأنواع المسماة عادة ما تكون مضغوطة أكثر من الأنواع المجهولة (التي يمكن للمترجم أن يلقيها) ، مما يقلل الوقت المستغرق في قراءة وكتابة ملفات التصريح (على سبيل المثال ، للبنيات المتزايدة) يعتبر الإرسال مريحًا للغاية ، لذلك ليست هناك حاجة للقيام بذلك عالميًا. ولكن قد يكون من المفيد المحاولة عندما تجد أجزاء بطيئة في التعليمات البرمجية الخاصة بك.

- import { otherFunc } from "other";
+ import { otherFunc, otherType } from "other";

- export function func() {
+ export function func(): otherType {
      return otherFunc();
  }

1.3 تفضيل الأنواع الأساسية على الأنواع المتعددة

تعد الأنواع المتعددة أداة رائعة: فهي تتيح لك التعبير عن نطاق القيم الممكنة لنوع ما.

interface WeekdaySchedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  wake: Time;
  startWork: Time;
  endWork: Time;
  sleep: Time;
}

interface WeekendSchedule {
  day: "Saturday" | "Sunday";
  wake: Time;
  familyMeal: Time;
  sleep: Time;
}

declare function printSchedule(schedule: WeekdaySchedule | WeekendSchedule);

لكن كل شيء له ثمن. في كل مرة يتم فيها تمرير وسيطة printSchedule

إليها ، يجب مقارنتها بكل عنصر من عناصر المجموعة. هذه ليست مشكلة لعنصرين. ولكن إذا كان هناك عشرات العناصر في المجموعة ، فقد يؤدي ذلك إلى إبطاء سرعة الترجمة. على سبيل المثال ، لإزالة العناصر الزائدة عن الحاجة ، يجب مقارنتها جميعًا في أزواج ، هذه وظيفة تربيعية. يمكن أن تحدث هذه الفحوصات عند تقاطع مجموعات كبيرة ، عندما يؤدي التقاطع لكل عنصر من عناصر المجموعة إلى ظهور أنواع ضخمة تحتاج إلى تقليلها. ويمكنك تجنب كل هذا باستخدام الأنواع الفرعية وليس المجموعات.

interface Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday";
  wake: Time;
  sleep: Time;
}

interface WeekdaySchedule extends Schedule {
  day: "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday";
  startWork: Time;
  endWork: Time;
}

interface WeekendSchedule extends Schedule {
  day: "Saturday" | "Sunday";
  familyMeal: Time;
}

declare function printSchedule(schedule: Schedule);

مثال أكثر واقعية هو محاولة نمذجة جميع أنواع عناصر DOM المضمنة. في هذه الحالة ، يُفضل إنشاء نوع أساسي HtmlElement

به عناصر متكررة تتوسع مع DivElement

، ImgElement

وما إلى ذلك ، بدلاً من إنشاء مجموعة ثقيلة DivElement | /*...*/ | ImgElement | /*...*/

.

2. استخدام روابط المشروع

عند إنشاء أي قاعدة بيانات كبيرة من نوع TypeScript ، من المفيد تنظيمها في عدة مشاريع مستقلة . كل منهم له tsconfig.json

تبعياته الخاصة في مشاريع أخرى. يمكن أن يساعد هذا في تجنب تنزيل عدد كبير جدًا من الملفات في تجميع واحد ، كما يمكن أن يسهل أيضًا مزج مخططات قاعدة التعليمات البرمجية المختلفة ومطابقتها.

هناك بعض الطرق البسيطة جدًا لتقسيم قاعدة التعليمات البرمجية الخاصة بك إلى مشاريع . على سبيل المثال ، مشروع لعميل ومشروع لخادم ومشروع مشترك بينهما.

             ------------
              |          |
              |  Shared  |
              ^----------^
             /            \
            /              \
------------                ------------
|          |                |          |
|  Client  |                |  Server  |
-----^------                ------^-----

يمكن أيضًا فصل الاختبارات في مشروع منفصل.

             ------------
              |          |
              |  Shared  |
              ^-----^----^
             /      |     \
            /       |      \
------------  ------------  ------------
|          |  |  Shared  |  |          |
|  Client  |  |  Tests   |  |  Server  |
-----^------  ------------  ------^-----
     |                            |
     |                            |
------------                ------------
|  Client  |                |  Server  |
|  Tests   |                |  Tests   |
------------                ------------

كثيرًا ما يسأل الناس: "ما حجم المشروع؟" إنه مثل السؤال ، "ما هو حجم الوظيفة؟" أو "ما هو الحجم الذي يجب أن يكون عليه الفصل؟" يعتمد الكثير على الخبرة. لنفترض أنه يمكنك مشاركة كود JS / TS باستخدام المجلدات ، وإذا كانت بعض المكونات مترابطة بما يكفي لوضعها في مجلد واحد ، فيمكنك اعتبارها تنتمي إلى نفس المشروع. أيضا ، تجنب المشاريع الكبيرة أو الصغيرة. إذا كان أحدهم أكبر من كل الآخرين مجتمعين ، فهذه علامة سيئة. من الأفضل أيضًا عدم إنشاء العشرات من مشاريع الملفات الفردية لأن هذا يزيد من النفقات العامة.

يمكنك أن تقرأ عن روابط المشاريع المشتركة هنا .

3. تكوين tsconfig.json أو jsconfig.json

يمكن لمستخدمي TypeScript و JavaScript دائمًا تخصيص مجموعاتهم باستخدام ملف tsconfig.json. يمكن أيضًا استخدام ملفات Jsconfig.json لتخصيص تحرير JavaScript .

3.1. تعريف الملفات

تأكد دائمًا من أن ملفات التكوين الخاصة بك لا تسرد الكثير من الملفات في وقت واحد.

يمكنك tsconfig.json

تحديد ملفات المشروع بطريقتين:

قائمة files

.
قوائم include

و exclude

؛

يتمثل الاختلاف الرئيسي بين الاثنين في أنه files

يحصل على قائمة بمسارات الملفات المصدر ، و include

/ exclude

يستخدم أنماطًا متقطعة لتحديد الملفات المطابقة.

من خلال التعريف files

، نسمح لـ TypeScript بتحميل الملفات بسرعة مباشرة. قد يكون هذا مرهقًا إذا كان المشروع يحتوي على العديد من الملفات وعدد قليل فقط من نقاط الدخول عالية المستوى. من السهل أيضًا أن تنسى إضافة ملفات جديدة إليها tsconfig.json

، ثم تتعرض لسلوك محرر غريب.

include

/ exclude

لا يتطلب تحديد كل هذه الملفات ، ولكن يجب على النظام اكتشافها بالمرور عبر الدلائل المضافة. وإذا كان هناك الكثير منهم ، فقد يتباطأ التجميع. بالإضافة إلى ذلك ، يتضمن التجميع أحيانًا العديد من الأشياء غير الضرورية.d.ts

واختبار الملفات ، والتي يمكن أيضًا أن تقلل السرعة وزيادة استهلاك الذاكرة. أخيرًا ، في حين أن exclude

هناك افتراضات مناسبة ، فإن بعض التكوينات ، مثل المستودعات الأحادية ، تحتوي على مجلدات "ثقيلة" من node_modules

هذا القبيل ستتم إضافتها في وقت الترجمة.

من الأفضل القيام بذلك:

حدد فقط مجلدات الإدخال الخاصة بمشروعك (على سبيل المثال ، كود المصدر الذي تريد إضافته أثناء التجميع والتحليل).
لا تخلط ملفات المصدر من مشاريع مختلفة في نفس المجلد.
إذا قمت بتخزين الاختبارات في نفس المجلد مثل المصادر ، فقم بتسميتها بحيث يمكن استبعادها بسهولة.
تجنب إنشاء عناصر تجميع كبيرة ومجلدات تبعية مثل node_modules

.

ملاحظة: بدون القائمة ، سيتم استبعاد exclude

المجلد node_modules

افتراضيًا. وإذا تمت إضافة القائمة ، فمن المهم الإشارة إليها صراحةً node_modules

.

هذا مثال tsconfig.json

:

{
    "compilerOptions": {
        // ...
    },
    "include": ["src"],
    "exclude": ["**/node_modules", "**/.*/"],
}

3.2 التحكم في إضافةtypes

بشكل افتراضي ، يضيف TypeScript تلقائيًا جميع node_modules

الحزم الموجودة في مجلد @types

، سواء قمت باستيرادها أم لا. هذا لجعل بعض الوظائف "تعمل فقط" عند استخدام Node.js و Jasmine و Mocha و Chai وما إلى ذلك ، نظرًا لأن هذه الأدوات / الحزم لا يتم استيرادها ، بل يتم تحميلها في البيئة العالمية.

قد يؤدي هذا المنطق أحيانًا إلى إبطاء تجميع وتحرير البرنامج. وحتى يؤدي إلى تعارض إعلان في العديد من الحزم العالمية التي تسبب أخطاء مثل هذا:

Duplicate identifier 'IteratorResult'.
Duplicate identifier 'it'.
Duplicate identifier 'define'.
Duplicate identifier 'require'.

إذا لم تكن هناك حاجة إلى الحزم العامة ، يمكنك تحديد مجلد فارغ في خيار "الأنواع" في tsconfig.json

/ jsconfig.json

:

// src/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Don't automatically include anything.
       // Only include `@types` packages that we need to import.
       "types" : []
   },
   "files": ["foo.ts"]
}

إذا كنت بحاجة إلى حزم عالمية ، فأضفها إلى الحقل types

.

// tests/tsconfig.json
{
   "compilerOptions": {
       // ...

       // Only include `@types/node` and `@types/mocha`.
       "types" : ["node", "mocha"]
   },
   "files": ["foo.test.ts"]
}

3.3 توليد المشروع المتزايد

العلم --incremental

يسمح نسخة مطبوعة على الآلة الكاتبة لانقاذ الدولة جمعت الماضية إلى ملف .tsbuildinfo

. يتم استخدامه لتحديد الحد الأدنى من مجموعة الملفات التي يمكن إعادة فحصها / الكتابة فوقها منذ آخر مرة ، مثل الوضع --watch

في TypeScript.

يتم تمكين الإنشاء التزايدي افتراضيًا عند استخدام composite

إشارة مرجعية عبر المشاريع ، ولكن يمكنه تسريع أي مشروع آخر أيضًا.

3.4. تخطي التحقق من صحة d.ts

بشكل افتراضي ، سيقوم TypeScript بفحص جميع .d.ts

الملفات في المشروع بالكامل للعثور على المشاكل والتناقضات. لكن هذا عادة ما يكون غير مطلوب. في كثير من الأحيان ، من المعروف أن هذه الملفات تعمل بالفعل: تم بالفعل التحقق من طرق توسيع النوع ، ولكن لا يزال يتم التحقق من الإعلانات المهمة.

يسمح TypeScript للعلامة skipDefaultLibCheck

بتخطي نوع التحقق في .d.ts

الملفات المتوفرة (على سبيل المثال ، في lib.d.ts

).

يمكنك أيضًا تمكين العلم skipLibCheck

لتخطي فحص جميع .d.ts

الملفات في التجميع.

غالبًا ما يخفي هذان الخياران أخطاء التكوين وتعارضات .d.ts

الملفات ، لذا يوصى باستخدامهما فقط لتسريع الإنشاء.

3.5 اختبارات متغيرة أسرع

قائمة الكلاب أو الحيوانات؟ هل يمكن أن تؤدي List<Dg>

إلى List<Animls>

؟ طريقة سهلة للعثور على الإجابة هي المقارنة الهيكلية بين الأنواع ، عنصرًا عنصرًا. لسوء الحظ ، قد يكون هذا الحل مكلفًا للغاية. ولكن إذا علمنا ما يكفي List<>

، فيمكننا تقليل عمليات التحقق من التخصيص لتحديد ما إذا كان من المسموح الرجوع Dog

إليه Animal

(أي بدون التحقق من كل عنصر List<>

). على وجه الخصوص ، نحتاج إلى معرفة تنوع نوع المعلمة T

. لا يمكن للمترجم الاستفادة الكاملة من التحسين إلا إذا كانت العلامة قيد التشغيل strictFunctionTypes

(وإلا فإنه سيستخدم فحصًا هيكليًا أبطأ ولكن أكثر تساهلاً). لذلك ، يوصى بالبناء باستخدام العلم --strictFunctionTypes

(والذي يتم تمكينه افتراضيًا ضمن --strict

).

4. إعداد أدوات التجميع الأخرى

غالبًا ما يتم تجميع TypeScript باستخدام أدوات بناء أخرى ، خاصةً عند إنشاء تطبيق ويب يمكنه استخدام أداة التجميع. يمكننا فقط تقديم بعض الأفكار ، ولكن بشكل عام يمكن تعميم هذا النهج.

بالإضافة إلى هذا الجزء ، تأكد من القراءة عن أداء الأداة التي اخترتها ، على سبيل المثال:

4.1 فحص النوع المتزامن

يتطلب فحص النوع عادةً معلومات من ملفات أخرى وهو مكلف نسبيًا مقارنة بالخطوات الأخرى مثل تحويل / كتابة التعليمات البرمجية. نظرًا لأن فحص النوع يمكن أن يستغرق وقتًا طويلاً ، فقد يؤثر على دورة التطوير الداخلية. أي أن دورة التحرير والترجمة والتشغيل ستصبح أطول ، وهذا أمر غير سار.

لذلك ، يمكن للعديد من أدوات البناء التحقق من الأنواع في عملية منفصلة ، دون حظر إنشاء الملف. على الرغم من أنه في هذه الحالة ، قد يتم تشغيل تعليمات برمجية خاطئة قبل أن يبلغ TypeScript عن الخطأ في أداة الإنشاء. في أغلب الأحيان ، سترى أولاً أخطاء في المحرر ولن تنتظر تشغيل الكود.

مثال على ذلك هو fork-ts-checker-webpack-plugin الخاص بـ Webpack ، أو ما شابهرهيبة محمل الورق .

4.2 إنشاء ملف معزول

بشكل افتراضي ، يتطلب إنشاء الملفات في TypeScript معلومات دلالية قد لا تكون محلية للملف. وهذا أمر ضروري لفهم كيف مثل ميزات const enum

و يتم إنشاؤها namespace

. لكن في بعض الأحيان يصبح التوليد أبطأ بسبب الحاجة إلى فحص الملفات الأخرى لتوليد النتيجة لملف عشوائي.

نادرًا ما نحتاج إلى ميزات تتطلب معلومات غير محلية. enum

يمكن استخدام النظاميين بدلاً من ذلك const enum

، ويمكن استخدام الوحدات بدلاً من ذلك namespace

. لذلك ، تحتوي TypeScript على علامة isolatedModules

لإلقاء الأخطاء على الميزات التي تتطلب معلومات غير محلية. باستخدام هذه العلامة ، يمكنك استخدام الأدوات التي تستخدم TypeScript APIs مثل transpileModule

أو برامج التحويل البرمجي البديلة مثل Babel بأمان .

لن يعمل هذا الرمز بشكل صحيح في وقت التشغيل مع تحويل ملف معزول لأن القيم يجب أن تكون مضمنة const enum

. لحسن الحظ ، isolatedModules

سيحذرنا مسبقًا.

// ./src/fileA.ts

export declare const enum E {
    A = 0,
    B = 1,
}

// ./src/fileB.ts

import { E } from "./fileA";

console.log(E.A);
//          ~
// error: Cannot access ambient const enums when the '--isolatedModules' flag is provided.

تذكر: isolatedModules

لا يسرع إنشاء الكود تلقائيًا. إنه يحذر فقط من استخدام ميزة قد لا تكون مدعومة. تحتاج إلى إنشاء وحدات منفصلة في أدوات إنشاء وواجهات برمجة تطبيقات مختلفة.

يمكنك إنشاء ملفات منعزلة باستخدام الأدوات التالية:

يحتوي ts-loader على علامة transpileOnly ، والتي توفر ملفات إنشاء معزولة باستخدام transpileModule

.
awesome-typescript-loader transpileOnly, transpileModule

.
API transpileModule TypeScript .
awesome-typescript-loader useBabel.
babel-loader ( ).
gulp-typescript isolatedModules

.
rollup-plugin-typescript .
ts-jest [ isolatedModules

true

].
يمكن أن تحدد ts-node خيار "transpileOnly" في حقل "ts-node" لملف tsconfig.json ولديها أيضًا علامة --transpile-only .

5. التحقيق في المشكلة

هناك طرق مختلفة لمعرفة أسباب حدوث خطأ ما.

5.1 تعطيل إضافات المحرر

يمكن أن تؤثر المكونات الإضافية على كيفية عمل المحرر. حاول تعطيلها (خاصة تلك المتعلقة بـ JavaScript / TypeScript) ومعرفة ما إذا كان الأداء والاستجابة يتحسنان.

بعض المحررين لديهم توصياتهم الخاصة لتحسين الأداء ، اقرأها. على سبيل المثال ، يحتوي Visual Studio Code على صفحة تلميحات منفصلة .

5.2. تمديد التشخيص

يمكنك تشغيل TypeScript مع --extendedDiagnostics

لمعرفة أين يقضي وقت المترجم:

Files:                         6
Lines:                     24906
Nodes:                    112200
Identifiers:               41097
Symbols:                   27972
Types:                      8298
Memory used:              77984K
Assignability cache size:  33123
Identity cache size:           2
Subtype cache size:            0
I/O Read time:             0.01s
Parse time:                0.44s
Program time:              0.45s
Bind time:                 0.21s
Check time:                1.07s
transformTime time:        0.01s
commentTime time:          0.00s
I/O Write time:            0.00s
printTime time:            0.01s
Emit time:                 0.01s
Total time:                1.75s

يرجى ملاحظة Total time

أنه لن يكون مجموع كل تكاليف الوقت المدرجة ، حيث أن بعضها متداخل ، والبعض الآخر لا يتم قياسه على الإطلاق.

المعلومات الأكثر صلة لمعظم المستخدمين:

حقل	القيمة
`Files`	عدد الملفات المضمنة في البرنامج (ما نوع الملفات التي يمكنك رؤيتها باستخدام `--listFiles` ).
`I/O Read time`	الوقت المستغرق في القراءة من نظام الملفات. وهذا يشمل قراءة المجلدات من `include` .
`Parse time`	الوقت المستغرق في مسح البرنامج وتحليله.
`Program time`	الوقت الإجمالي للقراءة من نظام الملفات ، ومسح البرنامج وتحليله ، بالإضافة إلى حسابات الرسم البياني الأخرى. يتم دمج هذه المراحل هنا لأنها تحتاج إلى تمكينها وتحميلها بمجرد إضافتها عبر `import` و `export` .
`Bind time`	الوقت المستغرق في تجميع معلومات دلالية مختلفة محلية لملف معين.
`Check time`	الوقت المستغرق في التحقق من الأنواع الموجودة في البرنامج.
`transformTime time`	الوقت المستغرق في إعادة كتابة TypeScript ASTs (الأشجار التي تمثل الملفات المصدر) في نماذج تعمل في بيئات وقت التشغيل القديمة.
`commentTime`	الوقت المستغرق في تقييم التعليقات في الملفات التي تم إنشاؤها.
`I/O Write time`	الوقت المستغرق في كتابة وتحديث الملفات على القرص.
`printTime`	الوقت المستغرق لحساب تمثيل السلسلة للملف الذي تم إنشاؤه وحفظه على القرص.

بالنظر إلى هذه المدخلات ، ما قد تحتاجه:

هل عدد الملفات / أسطر الكود يتوافق تقريبًا مع عدد الملفات في المشروع؟ إذا لم يكن كذلك ، فحاول استخدام --listFiles

.
هل القيم Program time

أو I/O Read time

تبدو كبيرة؟ تحقق مما إذا كانت الإعدادات صحيحة include

/exclude

يبدو أن هناك خطأ ما في المواعيد الأخرى؟ يمكنك ملء تقرير المشكلة! ما الذي سيساعدك في التشخيص:

ابدأ بما emitDeclarationOnly

إذا كانت القيمة printTime

عالية.
تعليمات تقرير مشاكل أداء المترجم

5.3 showConfig

ليس من الواضح دائمًا ما هي الإعدادات التي يتم إجراؤها عند بدء التشغيل tsc

، لا سيما بالنظر إلى tsconfig.jsons

إمكانية توسيع ملفات التكوين الأخرى. showConfig

يمكن أن يشرح ما سيحسب tsc

.

tsc --showConfig

# or to select a specific config file...

tsc --showConfig -p tsconfig.json

5.4. التتبع

تعمل مع traceResolution

وسوف اقول لكم لماذا تمت إضافة الملف إلى تجميع. البيانات واسعة جدًا ، لذا يمكنك حفظ النتيجة في ملف:

tsc --traceResolution > resolution.txt

إذا وجدت ملفًا لا ينبغي أن يكون موجودًا ، يمكنك تصحيح القائمة include

/ exclude

في الملف tsconfig.json

، أو ضبط الإعدادات مثل types

، typeRoots

أو paths

.

5.5 تشغيل واحد tsc

غالبًا ما يواجه المستخدمون أداءً ضعيفًا مع أدوات إنشاء تابعة لجهات خارجية مثل Gulp و Rollup و Webpack وما tsc --extendedDiagnostics

إلى ذلك. يمكن أن يشير التشغيل للعثور على تناقضات كبيرة بين TypeScript وأداة جهة خارجية إلى وجود أخطاء في التكوينات الخارجية أو عدم الكفاءة.

ماذا تريد أن تسأل نفسك:

هل هناك فرق كبير في أوقات tsc

الإنشاء باستخدام أداة TypeScript المدمجة؟
إذا كانت أداة الطرف الثالث تحتوي على أدوات تشخيص ، فهل يختلف الحل بين TypeScript وأداة الطرف الثالث؟
هل للأداة تكوينها الخاص الذي قد يتسبب في ضعف الأداء؟
هل تحتوي الأداة على تكوين لدمجها مع TypeScript والذي قد يتسبب في ضعف الأداء (مثل خيارات ts-loader)؟

5.6 تحديث التبعيات

في بعض الأحيان ، يمكن أن تؤثر الملفات المعقدة حسابيًا على التحقق من الكتابة في TypeScript .d.ts

. نادرًا ما يحدث ذلك. يتم حل هذا عادةً عن طريق الترقية إلى إصدار أحدث من TypeScript (أكثر كفاءة) أو إصدار أحدث من الحزمة @types

(والذي قد يعكس الانحدار).

6. مشاكل متكررة

عندما تواجه صعوبات ، سترغب في التعرف على حلول للمشاكل الشائعة. إذا لم يساعدك ما يلي ، يمكنك الإبلاغ عن المشكلة .

6.1 تم تكوينه بشكل غير صحيح للتضمين والاستبعاد

كما ذكرنا ، يمكن إساءة استخدام الخيارات include

/ exclude

.

مشكلة	سبب	تصحيح
`node_modules` تمت إضافته عن طريق الخطأ من مجلد فرعي أعمق.	لم يتم تكوينه `exclude`	`"exclude": ["/node_modules", "/.*/"]`
`node_modules` تمت إضافته عن طريق الخطأ من مجلد فرعي أعمق.	`"exclude": ["node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
تتم إضافة الملفات المخفية ذات النقطة بشكل عشوائي (على سبيل المثال `.git` ).	`"exclude": ["**/node_modules"]`	`"exclude": ["/node_modules", "/.*/"]`
تمت إضافة ملفات غير متوقعة.	لم يتم تكوينه `include`	`"include": ["src"]`

7. استكمال تقارير المشاكل

إذا كان مشروعك قد تم تكوينه بشكل صحيح بالفعل وبشكل مثالي ، فيمكنك ملء تقرير المشكلة .

يحتوي التقرير الجيد على وصف سهل المتابعة للمشكلة. أي أنه يحتوي على قاعدة بيانات للعديد من الملفات التي يمكن استنساخها بسهولة عبر Git. في هذه الحالة ، ليست هناك حاجة للتكامل الخارجي مع أدوات التجميع ، يمكن استدعاؤها من خلال tsc

، أو استخدام رمز معزول يستخدم TypeScript API. لا يمكنك تحديد أولويات قواعد البرمجة التي تتطلب مكالمات وإعدادات معقدة.

نعم ، هذا ليس من السهل تحقيقه دائمًا. خاصة لأنه من الصعب عزل مصدر المشكلة داخل قاعدة البيانات ، وهناك أيضًا اعتبارات حماية الملكية الفكرية. في بعض الحالات ، يمكنك أن ترسل إلينا اتفاقية عدم إفشاء إذا كنت تعتقد أن المشكلة ذات أهمية كبيرة.

بغض النظر عن قابلية تكرار المشكلة ، عند إكمال التقرير ، اتبع هذه النصائح ، وسوف تساعدنا في إيجاد حل.

7.1. تقرير مشاكل أداء المترجم

من حين لآخر ، تحدث مشكلات في الأداء أثناء الإنشاء والتحرير. ثم من المنطقي التركيز على مترجم TypeScript.

أولاً ، استخدم الإصدار "الليلي" من TypeScript للتأكد من أنك لا تواجه مشكلة ثابتة:

npm install --save-dev typescript@next

# or

yarn add typescript@next --dev

يجب أن يتضمن وصف مشكلة الأداء ما يلي:

نسخة مثبتة من TypeScript ( npx tsc -v

أو yarn tsc -v

).
إصدار Node الذي كان يعمل عليه TypeScript ( node -v

).
نتيجة التشغيل باستخدام الخيار extendedDiagnostics

( tsc --extendedDiagnostics -p tsconfig.json

).
من الناحية المثالية ، تحتاج إلى مشروع بحد ذاته يوضح المشكلة المطروحة.
سجل ملف التعريف المترجم (الملفات isolate-*-*-*.log

و *.cpuprofile

).

إنشاء ملف تعريف للمترجم من

المهم تزويدنا بتتبع تشخيصي عن طريق تشغيل Node.js v10 + --trace-ic

بالعلامة و TypeScript بالعلامة --generateCpuProfile

:

node --trace-ic ./node_modules/typescript/lib/tsc.js --generateCpuProfile profile.cpuprofile -p tsconfig.json

هذا ./node_modules/typescript/lib/tsc.js

يمكن استبدالها بأي مسار تثبيت إصدار مترجم نسخة مطبوعة على الآلة الكاتبة في. وبدلاً من ذلك tsconfig.json

يمكن أن يكون أي ملف تهيئة TypeScript. بدلاً من ذلك profile.cpuprofile

- ملف الإخراج الذي تختاره.

سيتم إنشاء ملفين:

--trace-ic

سيحفظ البيانات في ملف عرض isolate-*-*-*.log

(على سبيل المثال isolate-00000176DB2DF130-17676-v8.log

).
--generateCpuProfile

سيحفظ البيانات في ملف باسم من اختيارك. في المثال أعلاه ، هذا هو profile.cpuprofile

.

تحذير : قد تحتوي هذه الملفات على معلومات من مساحة العمل الخاصة بك ، بما في ذلك المسارات والتعليمات البرمجية المصدر. يتم إنشاء كلا الملفين بنص عادي ، ويمكنك تحريرهما قبل إرفاقهما بتقرير Github (على سبيل المثال ، عن طريق مسح المسارات التي قد تكشف عن معلومات حساسة).

ولكن إذا كانت لديك أي شكوك حول وضعها على Github ، فاكتب إلينا ، ويمكنك إرسال المعلومات على انفراد.

7.2 تقرير مشاكل أداء محرر

هناك العديد من الأسباب لضعف أداء التحرير. ويمكن لفريق TypeScript أن يؤثر فقط على أداء خدمة لغة JavaScript / TypeScript ، بالإضافة إلى التكامل بين خدمة اللغة وبعض المحررين (على سبيل المثال ، Visual Studio و Visual Studio Code و Visual Studio for Mac و Sublime Text). تأكد من تعطيل جميع المكونات الإضافية للجهات الخارجية في محررك. سيؤدي هذا إلى التحقق من أن المشكلة مرتبطة بـ TypeScript نفسها.

تعد مشكلات أداء المحرر أكثر تعقيدًا بعض الشيء ، لكن نفس الأفكار تنطبق: تعتبر قواعد الكود الصغيرة المستنسخة ذات المشكلة القابلة للتكرار مثالية. وفي بعض الحالات ، يمكننا التوقيع على اتفاقية عدم الإفشاء للتحقيق في المشكلات وعزلها.

إضافة البيانات منtsc --extendedDiagnostics

، ولكن أفضل إذا كان هناك تتبع TSServer.

الحصول على سجلات TSServer في Visual Studio Code

افتح شريط الأوامر ، ثم:
اضبط الخيار «typescript.tsserver.log»: «verbose»,

.
أعد تشغيل VS Code وأعد إظهار المشكلة.
في كود VS ، قم بتشغيل الأمر TypeScript: Open TS Server log

.
يجب فتح الملف tsserver.log

.

ملاحظة : قد يحتوي سجل TSServer على معلومات من مساحة العمل الخاصة بك ، بما في ذلك المسارات وكود المصدر. إذا كانت لديك أي شكوك حول وضعه على Github ، فاكتب إلينا ويمكنك إرسال المعلومات بشكل خاص.

أداء TypeScript