<p>TypeScript 4.0 خطة التكرار</p>

هل تفكر في تضمين https://github.com/microsoft/TypeScript/pull/29818 في 4.0 ربما خلف العلم التجريبي؟

يصبح الأمر معقدًا بسبب التغيير في تعريف وظيفة المصنع في حد ذاته.

قد يكون من المثير للاهتمام تقديم تعريف نوع افتراضي مصنع منفصل ، على الرغم من ذلك ؛ على سبيل المثال ، JSX.Factory ، أو React.JSX.Factory ، والتي يمكن أن يستخدمها TypeScript بعد ذلك للاستدلال. لست متأكدًا تمامًا من أن ترجمة قواعد JSX النحوية إلى استدعاءات وظيفية كافية أو فعالة ، ولكن نظرًا لأنها نوع افتراضي ، فلا يلزم أن تتوافق مع أي كيان جافا سكريبت ملموس. الخطر ، بالطبع ، هو الدخول في نفس الموقف الذي نواجهه الآن ، مع مجموعة من الأنواع الافتراضية التي انتهى بها الأمر إلى الحد من نوع الأمان ، ليس فقط للأطفال ، ولكن أيضًا للعديد من الميزات التي تم تقديمها بعد React 15.

هل تفكر في تضمين https://github.com/microsoft/TypeScript/pull/24738 في 4.0 أيضًا؟

أنا حزين بعض الشيء لأنني لا أرى أي ذكر لـ # 33038 [140 والعلاقات العامة الفعلية بواسطةweswigham] أو # 202 [390] بينما التذاكر مثل # 15230 [27] تعتبر "طلبًا مرتفعًا". أدرك أنه لا يمكنك حقًا المقارنة أو تحديد الأولويات على أساس "الإعجابات" ولكن سيكون من الرائع أن يكون هناك تحديث لخارطة الطريق حول هذه الأشياء ، خاصة وأن 4.0 يبدو فرصة جيدة لتقديم ميزة مثل هذه. 🙏

مشكلة عمرها 3.5 عام تنتظر التعليقات مع ما يقرب من 200 تعليق # 13778 مع كتابة غير دقيقة لأشياء مثل إتلاف الصفيف. Pwetty pwease هل يمكننا تنفيذ الإصلاح 🙏

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

أمثلة:

• قد تكون العلامات التجارية الاسمية جيدة ، لكن هل سيتوافق ذلك مع اتجاه اللغة المستقبلي حول الاسمية؟ لدي هذا القلق بشأن أنواع العناصر النائبة بصفتي الشخص الذي اقترحها.
• يعد undefined على توقيعات الفهرس مثالًا على شيء مثير للاهتمام ، لكننا لا نريد إضافة سلوك يجعل الأمر أكثر صعوبة بالنسبة لـ 90٪ من الأشخاص الذين يعملون بالفعل وفقًا للافتراضات الحالية. إن العثور على نهج يؤلف ويسمح للمستخدمين باعتماد هذه الفحوصات بشكل تدريجي ليس شيئًا واضحًا بالنسبة لنا. حتى لو كان ذلك ممكنًا من الناحية الفنية مع مجموعة من الأنواع الشرطية وفحوصات المترجم الخاصة ، فإن هذه الحلول تميل إلى أن تكون اختراقًا واضحًا للغاية وتتعطل بسرعة.

قد تكون العلامات التجارية الاسمية جيدة ، لكن هل سيتوافق ذلك مع اتجاه اللغة المستقبلي حول الاسمية؟

DanielRosenwasser ما هو اتجاه اللغة المستقبلي في رؤيتك؟

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

• الاسمية القائمة على التصريح "التقليدية" (على سبيل المثال ، ما تراه في معظم لغات OO)
• أنواع غير شفافة (الأنواع التي تكون محتوياتها غير معروفة تمامًا بالخارج)
• الأسماء المستعارة المميزة (عضو واحد struct s في C / C ++ / C # ، newtype في Haskell ، فصول مضمنة في Kotlin)
• وحدات القياس (طريقة لترميز التحليل البعدي في اللغة)

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

لدى RyanCavanaugh تشبيه رائع حول هذا حيث يسأل 3 أطفال والديهم عن حيوان أليف. يريد المرء كلباً ، والآخر يريد قطة ، والآخر يريد سمكة. يسألون والديهم "متى نحصل على حيوان أليف؟" من الواضح أنهم جميعًا متفقون على أنهم يريدون حيوانًا أليفًا ، لكن كل منهم يريد حيوانًا أليفًا مختلفًا!

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

أرغب في الحصول على https://github.com/microsoft/TSJS-lib-generator/pull/858 في TypeScript 4.0 .

DanielRosenwasser بادئ ذي بدء شكراً لك على الكتابة 🙇

هل يمكنك أن تشرح قليلاً ما هي حالات الاستخدام التي تتناولها الأنواع الاسمية فعلاً لـ TypeScript؟

أولاً: لا تتردد في إرسالي إلى جدار نصي ضخم أو إعادة شراء وسأقرأه:]

لا أعني الأنواع المبهمة مثل أنواع العناصر النائبة - أعني ما تسميه الأنواع الاسمية "التقليدية".

لطالما شعرت أن الأنواع الاسمية تتعارض مع JavaScript ولهذا السبب لم تنجح المحاولات السابقة بشكل جيد. هناك طرق لجعلها تعمل بشكل جيد (تتبادر إلى الذهن البروتوكولات في الكتابة السريعة والطباعة في haskell على أنها "اسمية ولكنها قابلة للتمديد من الخارج") وأنا متأكد من أنك على دراية بمعظم الطرق "الراسخة" (أنا لنفترض أن "وحدات القياس" هي غمزة F #).

لقد وجدت الكثير من الأشخاص يطلبون أنواعًا رمزية (كما هو الحال في "التقليدية") ولكن ليس هناك الكثير من المقالات المكتوبة حول _لماذا_.

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

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

أشعر نوعًا ما بأن الكتابة المطبوعة هي بالفعل معبرة بدرجة كافية. ما أود أن أراه شخصيًا هو تكامل أفضل للأدوات.

• دعم ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• المكونات الإضافية للمترجم https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• الغزل pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

بسبب ما ورد أعلاه ، من الشائع رؤية حلول عالية الجودة ومبتكرة. تحتوي معظم مشاريع التفاعل على برنامج babel للتفاعل-hot-Load (ملحقات المحول البرمجي) ، كما تتطلب بعض أنظمة CSS أيضًا برنامج babel لتحويلات وقت التجميع. يتطلب استخدام وحدات pnp أو esm أو حتى CSS المزيد من الأدوات والحلول لقيود tsc.

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

على أي حال أنا مجرد شخص عشوائي من الإنترنت.

DanielRosenwasser ربما يمكن مراجعة https://github.com/microsoft/TypeScript/pull/29374 في الوقت المناسب لـ 4.0؟ أعتقد أنه يغطي العديد من (معظم؟) من this - قبل- super يميل الناس إلى السؤال عنها.

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

https://github.com/microsoft/TypeScript/issues/16577

شكرًا لك على تركيزك على الأدوات حول الكتابة المطبوعة! كنت آمل أن تفكر في توفير تكامل أوثق مع https://github.com/microsoft/tsdoc. توفر الكثير من اللغات الحديثة الأخرى مثل go and rust أدوات التوثيق فور إخراجها من الصندوق وتشجع المطورين على كتابة تعليقات قياسية ، ولكن الكتابة المطبوعة غير متوفرة في هذا الصدد.

سيكون أمرًا رائعًا أن يتم اختيار # 31445 ، فقد كان هذا بمثابة كسر للصفقة بالنسبة لنا وأعتقد أن الكثير من الأشخاص (بناءً على عدد المراجع التي تحتوي عليها هذه المشكلة)!

يمكن تضمين https://github.com/microsoft/TypeScript/pull/38967 في TypeScript 4.0 ، وربما أيضًا https://github.com/microsoft/TypeScript/pull/35608 .

لقد وجدت أن الأشخاص يطلبون تضمين كل شيء في الإصدار 4.0 😆

هل تشعر أن TS يفقد الزخم؟ هل عمليات التوحيد الفارغة وتخصيصات الدوائر القصيرة للإصدار 4.0.0 التالي _major_؟ لا أهداف كبيرة وأفكار طموحة بعد الآن؟

بالنسبة للتخصص التالي ، أتوقع:

• أعلى الكتابة الرقيقة
• الكتابة المعتمدة؟ وظائف على مستوى النوع؟ (حسنًا ، يمكن أن يكون هذا الإصدار 5.0.0)
• الكتابة الاسمية
• وحدات الماكرو
• دعم المحولات في tsconfig.json
• تجميع إلى WASM (من بعض مجموعات اللغات الفرعية)

@ canonic-epicure Agree ، حاليًا يبدو وكأنه 3.10 للإصدار التالي

هل تشعر أن TS يفقد الزخم؟ هل عمليات التوحيد الفارغة واختصار الدائرة للإصدار 4.0.0 الرئيسي التالي؟ لا أهداف كبيرة وأفكار طموحة بعد الآن؟

TypeScript لا يتبع semver. لا يوجد v0.10 أو v1.10 أو v2.10 أو v3.10. لذلك هذا في الواقع معلم عادي. إنه لأمر غريب بعض الشيء أن يتوقع الناس الكثير من التغييرات في 4.0 لكنهم لا يقولون أي شيء في 3.9 أو خطة التكرار السابقة. 🙈

وظائف على مستوى النوع

يمكن type X<T> = T القيام بذلك على مستوى ما. (لا يدعم وظائف الترتيب الأعلى.)

وحدات الماكرو

IMO لا يلبي هدف Typescript.

دعم المحولات في tsconfig.json

جرب: https://github.com/cevek/ttypescript

تجميع إلى WASM (من بعض مجموعات اللغات الفرعية)

هل تبحث عن https://www.assemblyscript.org/

حسنًا ، 4.0.0 هو مجرد إصدار ثانوي تالي ، من الجيد معرفة ذلك.

بخصوص "وحدات الماكرو لا تفي بهدف TS" و "استخدام ttypescript للمحولات" ( ts-patch يعمل بشكل أفضل) - هذا يشبه حركة jedi - "هذه ليست الميزة التي تحتاجها". لا ، وحدات الماكرو والمحولات خارج الصندوق من فضلك. لقد تم طلبها منذ سنوات.

أريد أيضًا ماركو في TypeScript ولكن هناك بالفعل العديد من الأسباب ضد ذلك.

1. إذا كان بإمكان Marco إنشاء كود JavaScript مختلف ، فإنه يقوم بإنشاء بناء جملة جديد غير من النوع ، وبالتالي فهو امتداد لمواصفات ES. يُعد enum ، import x = require(...) ، module استثناء لهذه القاعدة ولكنها تأتي من وقت مبكر لـ TypeScript.

2. إذا كنت ترغب في استخدام Marco عبر ملفات مختلفة لإنشاء ملفات JS مختلفة ، فمن المستحيل إسقاط كل أنواع بناء الجملة للحصول على ملف JavaScript.

3. يمكن أن يزيد ماركوس من وقت التحليل والتجميع ، ومن المحتمل أن يتم إساءة استخدامه.

4. إذا كان بإمكان Marco إرسال ملفات JS مختلفة بناءً على معلومات النوع ، فسيؤدي ذلك إلى جعل Babel مستحيلاً التعامل مع بناء الجملة هذا. لذا فإن هذا السلوك ينتهك قاعدة isolatedModules (استثناء: const enum و module )

5. إذا كان ماركو لا يمكنه سوى عمل "مستوى كتابة ماركو" ويمكن محوه بواسطة Babel بأمان ، فإنه يصبح عديم الفائدة كثيرًا ولكنه لا يزال مفيدًا للأنواع عالية المستوى / البرامجية. لذلك فهو لا ينتهك أي أهداف ، لكني أشك فيما إذا كان فريق TypeScript سيهتم بالفكرة. (لقد قمت بعمل عرض توضيحي على https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

@ جاك - وركس أنا لا أفهم نقاطك. ربما تقصد أن وحدات الماكرو ستمتد المحلل اللغوي وتنشئ synatx جديدًا؟

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

ستكون المناقشة خارج الموضوع لهذا الموضوع ، ربما لتستمر على #compiler channel في الخلاف؟

يمكن تضمين # 38597 في TypeScript 4.0？

تضمين التغريدة

يعد undefined في تواقيع الفهرس مثالًا على شيء مثير للاهتمام ، لكننا لا نريد إضافة سلوك يجعل الأمر أكثر صعوبة بالنسبة لـ 90٪ من الأشخاص الذين يعملون بالفعل وفقًا للافتراضات الحالية.

مجرد فضول كيف تعرف أنه 90٪ من الناس؟

wongjiahau تم إنشاء الرقم عرضًا من أجل التفسير. لست متأكدًا مما إذا كانت هذه هي النقطة المحددة التي تسأل عنها.

فقط كإخطارات فردية: لن يعمل فريقنا في 19 حزيران (يونيو) ، لذلك سنقوم بدفع الجدول أكثر قليلاً. من المقرر الآن أن يتم شحن الإصدار التجريبي بحلول الخميس المقبل ، 25 يونيو.

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

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

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

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

4.0 هو بالتأكيد علامة فارقة وليس "الإصدار التالي من 3.9".

@ typecript-bot قم بإنشاء الإصدار 4.0

HeyaDanielRosenwasser ، لقد بدأت في إنشاء فرع release-4.0 من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

Kingwl إذا كانت هذه علامة فارقة ، فما هي تلك الأشياء الكبيرة أو على الأقل ما هي ميزة البطل؟ لا أرى شيئًا رائعًا في قائمة ميزات اللغة في الجزء العلوي من هذه المشكلة. لا شيء غير عادي مقارنة بمعظم إصدارات 3.x.
بالطبع قد تقول إنه مجرد كسر للتغيير الذي يتطلب إصدارًا رئيسيًا ، ولكن بعد ذلك من الصعب تسميته "معلم".

wgebczyk في رأيي ، تعتبر المجموعات المتباينة التي تحتوي على عناصر tuple معنونة هي الحدث الرئيسي.

تضمين التغريدة لكن في الواقع Variadic Tuples هو.

تضمين التغريدة بوصة من الحجر.

إنه هناك: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
متى سيصل هذا الإصدار المستقر؟ لا أطيق الانتظار لتطبيق هذا في الترميز اليومي في VS Code.

@ mk0y وفقًا للرسالة الافتتاحية حول 18 أغسطس.

wgebczyk إصداراتنا تستند إلى الوقت ؛ يحتوي كل إصدار على ما يقرب من ثلاثة أشهر من عمل الفريق. كانت سياسة الإصدارات الرئيسية الخاصة بنا (n = n + 0.1) متسقة في آخر 20 إصدارًا ، لذا نأمل أن يتوقف هذا عن كونه مفاجأة للناس في مرحلة ما 😅

هل تفكر في السماح بنوع symbol للفهرسة في الإصدارات الثانوية التالية؟ هل يمكنك تحقيق ودمج طلب السحب 26797 ؟

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.0 إلى 4.0.1-rc من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

@ typecript-bot sync release-4.0

HeyaDanielRosenwasser ، لقد بدأت في مزامنة release-4.0 مع الأستاذ من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

@ typecript-bot sync release-4.0

HeyaDanielRosenwasser ، لقد بدأت في مزامنة release-4.0 مع الأستاذ من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

weswigham mmmmmmmmmmmmmmmm ، البوت يكرهني) :) :) :) :):

لا داعي للاندفاع على الإطلاق ، لكنني فعلت ذلك يدويًا وقدمت هذا: https://github.com/microsoft/TypeScript/issues/39869

هل توجد بالفعل خارطة طريق لما بعد 4.0 في مكان ما؟ أرغب في تعزيز # 37582 نظرًا لوجود طلب متزايد أكثر فأكثر (# 39965 ، # 38149 ، # 27481 ، # 39965 ، # 38546). يبدو لي أنها قضية محددة النطاق بشكل معقول.

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

@ typecript-bot bump release-4.0

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.0 إلى 4.0.2 من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

إنه 20 أغسطس :)

هيه ، لا يزال يوم 19 أغسطس هنا ، وحتى بعد 20 دقيقة من الآن أعتقد أنه سيتعين عليك الانتظار قليلاً. لدينا إصدارات ليلية في npm إذا كنت لا تستطيع أن تأخذ دقيقة أخرى! 😄

في انتظار الإصدار ، خرج بالفعل في npm :)

@ typecript-bot bump release-4.0

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.0 إلى 4.0.3 من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

@ typecript-bot bump release-4.1.0 تحديث

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.1 إلى 4.1.1-rc من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

أوه لا

@ typecript-bot bump release-4.0

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.0 إلى 4.0.4 من أجلك. هذا هو الرابط لأفضل تخميني في السجل .

@ typecript-bot bump release-4.0

HeyaDanielRosenwasser ، لقد بدأت في تحديث رقم الإصدار على release-4.0 إلى 4.0.5 من أجلك. هذا هو الرابط لأفضل تخميني في السجل .