Typescript: دعم البرنامج المساعد للمحولات المخصصة

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

لا أرغب في الحصول على واجهة برمجة تطبيقات مكشوفة. بدلاً من ذلك ، أفضل طريقة لتسجيل تحويلاتي المخصصة فقط عن طريق تحديدها في tsconfig.json بدلاً من الاضطرار إلى استخدام TS-Compiler API. نظرًا لأن استخدام TS-Compiler API يعني أنه لم يعد بإمكاني استخدام أداة سطر أوامر tsc والتي يمكن أن تعني أيضًا أنها لم تعد تتكامل بشكل جيد في أدوات البناء ومهام سير العمل الحالية.

أي تحديث حول الوثائق والعينات؟ تضمين التغريدة

MichaReiser يمكنك كتابة مترجم بسيط على أساس API (عينة هنا ). نحن في الواقع نستخدم TS بكثافة في Yahoo Finance وكانت واجهة برمجة التطبيقات العامة للمحول رائعة.

هذه بعض المحولات التي كتبناها بعد أن أصبحت علنية:
https://github.com/longlho/ts-transform-system-import
https://github.com/longlho/ts-transform-img
https://github.com/longlho/ts-transform-react-intl
https://github.com/longlho/ts-transform-css-modules-transform

mhegazy lmk إذا كنت بحاجة إلى مساعدة في توثيق / جمع العينات

تضمين التغريدة
شكرا على عينتك.

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

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

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

تضمين التغريدة أنا لا أقول أنها كافية للنظام البيئي ، فقط جيدة بما يكفي للخطوة الأولى نحوها.

أرغب في إضافة دعم للتحويلات في gulp-typecript ، لكنني أريد منع جميع مكونات TypeScript الإضافية (لـ gulp و webpack وما إلى ذلك) تقترح واجهة برمجة تطبيقات مختلفة. وقد تضيف TypeScript طريقة مختلفة لتكوين هذا لاحقًا. فهل لديك حاليًا خطط لإضافة هذا في المستقبل القريب أو البعيد؟

مرحبًا بالجميع ، أحاول أن أكتب معالجًا أوليًا ، لكن لا شيء يخرج: [

في الحقيقة لدي سؤالان:

• كيفية إنشاء جزء AST من سلسلة؟
• كيف تضيف الاستيراد؟

// 1. Input
class Foo {
    templateString = 'some value';
}

// 2. After transformation
import __LIB__ from '@external/lib';

class Foo {
    templateString = (function compiledTemplate(deps) {
        // ...
        return result;
    })({lib: __LIB__});
}

// 3. Expected result
var lib_1 = require("@external/lib");
var Foo = (function () {
    function Foo() {
        this.templateString = (function compiledTemplate(deps) {
            // ...
            return result;
        })({ lib: lib_1 }); 
    }
    return Foo;
}());

مثال مبسط: https://github.com/RubaXa/typescript-api-questions/tree/master/import-add

⬆️ ⬆️ ⬆️
longlho ، mhegazy هل يمكنك إعطاء أي تلميح؟

RubaXa نظرًا لأنك قمت بإضافة تصريح الاستيراد في تحويل ، فهو ليس ملزمًا أو محددًا من النوع. نظرًا لأنه لم يكن ملزمًا أو نوعًا محددًا ، لا يمكننا تحليل __LIB__ في تعبيرك إلى __LIB__ في الإعلان.

يتمثل أحد الخيارات في استخدام استيراد اسم بدلاً من استيراد افتراضي ، بحيث يكون إصدارك شيئًا مثل:

import * as __LIB__ from "@external/lib"

حيث لا يوجد تسمع يمكن أن يحدث.

الآخر يحتفظ بمعرف تم إنشاؤه لإقرار الاستيراد ، وفقًا للرمز البريدي المرفق

RubaXa إذا كان هدفك هو تمرير كائن الوحدة بالكامل ، فربما تريد استخدام بناء الجملة import * as __LIB__ from "@external/lib" (الذي لا يتطلب تسمية مستعارة) وليس import __LIB__ from "@external/lib" لأن الأخير يستورد default تصدير

نعم ، نقوم بعمل import * as foo في محول وحدات CSS الخاص بنا أيضًا لمنع التعرّف. على الرغم من أنه سيكون من الجيد الاستفادة من ذلك لتضمين بعض الصادرات المسماة

rbuckton O ، شكرًا جزيلاً!
هل مازلت مهتمًا بكيفية إنشاء جزء AST عشوائي من سلسلة؟

function createFragmentFromString(code: string) {
  // ????
}

function visitPropertyDeclaration(node) {
    if (ts.isIdentifier(node.name) && node.name.text === "templateString") {
        // ...
        return ts.updateProperty(
            node,
            ts.visitNodes(node.decorators, visitor),
            ts.visitNodes(node.modifiers, visitor),
            ts.visitNode(node.name, visitor),
            ts.visitNode(node.type, visitor),
            createFragmentFromString('(function compiledTemplate() { /* ... */ })()')
        );
    }
    return node;
}

هذا ما كنت آمل أن يتصرف دعم المحولات وسير العمل كما هو الحال في TypeScript.

https://www.dartlang.org/tools/pub/transformers

أنا أيضًا مهتم جدًا بهذه الميزة.

كما ذكر MichaReiser
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.

أحب أن أرى مدخلات من الخبراء / المترجم المطبوع عليه DEV.

يبدو أن شخصًا ما قد قام بلف الكتابة المطبوعة لعرض هذه الوظيفة. https://github.com/cevek/ttypescript

يبدو أيضًا أن ts-loader لديه: https://www.npmjs.com/package/ts-loader#getcustomtransformers ----- before-transformerfactory - after-transformerfactory ----

أعتقد أن هذا شيء يمكن أن يصل إلى الإصدار 2.8 المطبوع على الورق أو على الأقل في خارطة الطريق في وقت ما ،ahejlsbergmhegazyDanielRosenwasser ما رأيك ؟ بهذه الطريقة ، قد تكون المحولات المخصصة أكثر شيوعًا وبالتالي أكثر قوة. إن وجود خيار للمكوِّن الإضافي في Transfromer من منظور tsconfig.json من شأنه أن يبسط الحياة كثيرًا.

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

mhegazy هل هو قرار مدروس أم أنه خارج النطاق لمجرد انخفاض اهتمام المجتمع؟

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

من فضلك ، توقف عن تجزئة واجهة البرنامج المساعد للمحولات. ثبّت واجهة برمجة تطبيقات البرنامج المساعد أعلى واجهة برمجة تطبيقات Transfomer وفضحها في tsconfig.json.

ts-loader ، parcel-plugin- typecript ، rollup -plugin-type2 ، ts-transformer-keys ، ttypescript وغيرها.

يوفر كل واحد منهم طريقة تسجيل البرنامج المساعد المخصص وتنسيق نقطة إدخال البرنامج المساعد المخصص. انها طريقة ts plugin hell.

يدعم cevec / ttypescript الآن جميع تنسيقات محول المحولات الشائعة. إنه غلاف مُسقط فوق جميع الوحدات النمطية المطبوعة وأوامر tsc و tsserver (فقط وقت تشغيل صغير ts.createProgram patch). يمكن تكوين Webpack ts-loader و rollup-plugin-typecript2 بسهولة باستخدام ttypescript.

يقترح TTypescript تنسيق البرنامج المساعد العالمي للمحول ، لكن المحولات الحالية مدعومة أيضًا.

{
    "compilerOptions": {
        "plugins": [
            { "transform": "ts-transform-graphql-tag" },
            { "transform": "ts-transform-css-modules", "type": "config" },
            { "transform": "ts-nameof", "type": "raw", "after": true}
            { "transform": "./transformers/my-transformer.ts", "someOption1": 123, "someOption2": 321  }
        ]
    },
    "exclude": ["node_modules", "transformers/**/*"]
}

أي أخبار عن هذا؟ يبدو لي أن مؤلفي TypeScript لا يريدون بطريقة ما السماح للمحولات المخصصة على Vanilla TypeScript - هذا عار ، ستكون ميزة رائعة.

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

لا يريدون API / سطحًا آخر للاحتفاظ به خوفًا من التسبب في صعوبة كسر الأشياء في الأجزاء الداخلية.

بعد 3 سنوات من العمل مع الكتابة المطبوعة ومراقبة تطورها ، توصلت إلى نتيجة بسيطة. Microsoft لديها أنواع مفتوحة المصدر بمعنى _code_ ، ولكن ليس بمعنى _العملية_. في معظم الحالات ، تكون المشاريع مفتوحة المصدر مدفوعة إلى حد ما بالمجتمع سواء في القرارات أو في الترميز ، وينبغي أن تكون هذه هي الطريقة الطبيعية للتطور. هل تتذكر مفترق IO.js الخاص بـ node.js؟ أدرك المجتمع أن مصالح الشركة لم تكن متوافقة تمامًا مع نموذج حوكمة المصدر المفتوح المشترك ، وأنهم ببساطة متشعبون. آمل ألا يحدث هذا لـ TypeScript ، ولكن على Microsoft أن تأخذ هذا الاحتمال في الاعتبار.
لأكون واضحًا ، أنا لا ألوم المطورين ، على أي حال ، إنهم يقومون بعمل رائع حقًا.
فقط 2c ، آسف على OT.

Microsoft لديها أنواع مفتوحة المصدر بمعنى الكود ، ولكن ليس بمعنى العملية.

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

تريد أيضًا تسمية الفريق الأساسي بـ "Microsoft". كان الفريق الأساسي هو أقل فريق واجهته من Microsoft على الإطلاق. لقد خاضوا معارك للسيطرة الكاملة على إيقاع إطلاقهم ، بعد أن تأسسوا على السيطرة الكاملة على محتوى إطلاقهم. كما ناضلوا من أجل الانفتاح والشفافية. قاتلوا للانتقال إلى GitHub من CodePlex. من المسلم به أنها لم تعد فريدة من نوعها في Microsoft حيث تبنت العديد من الفرق الأخرى نموذجها ، لكنهم ، على حد علمي ، هم الذين بدأوا كل شيء ، مع متابعة فريق VSCode بسرعة بعد ذلك.

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

ما أفهمه هو أن هذا هو نفسه # 16607 ، أم أن هذا سيحقق هدفًا مختلفًا؟ بصفتي مؤلف مكون إضافي حديث جدًا ، أود أيضًا أن أرى هذا مكشوفًا - بما في ذلك عند العمل مع TypeScript باستخدام المكون الإضافي Babel.

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

أريد إضافة 2 سنت هنا. ربما سمع البعض منكم عن المشروع الرائع babel-plugin-macros . في الأساس ، بدلاً من وجود الآلاف من ملحقات Babel المختلفة ، يمكن أن يكون هناك المكون الوحيد الذي يتم تشغيله بعد ذلك بواسطة رمز مستخدم لإجراء تحويل. نظام شفاف بذهول دون الحاجة إلى العبث بالتهيئة طوال الوقت. يعد هذا أمرًا رائعًا بشكل خاص لمشاريع مثل CRA التي تدعم وحدات الماكرو ولكنها تمنع التكوين الإضافي.

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

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

FredyC هذا مشروع رائع ، لكننا نحتاج إلى حل هذه المشكلة من أجل إدخال شيء من هذا القبيل بسهولة في المترجم عند استخدام tsc فقط. على سبيل المثال ، مع babel-plugin-macros ، لا يزال يلزم تحديده في .babelrc وسيكون من الجيد تحديد شيء من هذا القبيل في الكتابة المطبوعة في tsconfig.json .

في الواقع ، هل تقترح أنه سيكون من الجيد أن يكون لديك سلوك مشابه لـ babel-plugin-macro مدمج في TypeScript ولن يكون من الضروري إجراء أي تكوين؟ قد يكون هذا رائعًا ، لكنني شخصياً أفضل حلًا قابلًا للتكوين يسمح بتحديد محولات مخصصة في tsconfig.json ومن ثم يمكن تحديد إصدار من babel-plugin-macros الذي يدعم العقد المنبثقة.

dsherret نعم ، لا أتوقع أن يكون جزءًا من TypeScript نفسها. ومع ذلك ، يمكنني أن أتخيل أنه بمجرد أن يصبح التحويل جاهزًا ، يمكن أن يكون من السهل إعداد غلاف صغير يشبه tsc مثل غلاف والذي من شأنه حقن هذا التحويل لوحدات الماكرو والباقي من كود مستخدم.

تحرير: في الواقع ، الغلاف الصغير موجود بالفعل ، مع https://github.com/cevek/ttypescript المذكور أعلاه ، سيكون من السهل إرشادك لاستخدام ذلك جنبًا إلى جنب مع المكوِّن الإضافي لوحدات الماكرو العالمية وهو مكسب للطرفين.

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

لا يريدون API / سطحًا آخر للاحتفاظ به خوفًا من التسبب في صعوبة كسر الأشياء في الأجزاء الداخلية.

بعد 3 سنوات من العمل مع الكتابة المطبوعة ومراقبة تطورها ، توصلت إلى نتيجة بسيطة. Microsoft لديها أنواع مفتوحة المصدر بمعنى _code_ ، ولكن ليس بمعنى _العملية_. في معظم الحالات ، تكون المشروعات مفتوحة المصدر مدفوعة إلى حد ما بالمجتمع المحلي سواء في _القرارات _ و _ في _ الترميز ، وينبغي أن تكون هذه هي الطريقة الطبيعية للتطور. هل تتذكر مفترق IO.js الخاص بـ node.js؟ أدرك المجتمع أن مصالح الشركة لم تكن متوافقة تمامًا مع نموذج حوكمة المصدر المفتوح المشترك ، وأنهم ببساطة متشعبون. آمل ألا يحدث هذا لـ TypeScript ، ولكن على Microsoft أن تأخذ هذا الاحتمال في الاعتبار.
لأكون واضحًا ، أنا لا ألوم المطورين ، على أي حال ، إنهم يقومون بعمل رائع حقًا.
فقط 2c ، آسف على OT.

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

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

أعتقد أن هذا نقد غير عادل pietrovismara. أوافق على أن هذه ميزة لا غنى عنها ، لكن هذه ليست "Microsoft" تحظر هذه الميزة. يقول الفريق ، كما أفهمه ، إنه ليس من السهل دعم ذلك ولهذا السبب لم يضيفوا هذه الميزة حتى الآن.

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

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

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

... مازلت منتظرا :(

نعم ، ما زلت تنتظر ... ولكن في انتظار ماذا ، تم عمل شيء؟

هل هناك أي حل أفضل من ttypescript الآن؟
هل يخطط مطورو TypeScript في النهاية لدعم المكونات الإضافية؟

يمكنك إنشاء مترجم خاص بك ؛-)

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

لقد مر أكثر من عامين (واو!) *. هل الناس منفتحون على إعادة التفكير في إيجابيات وسلبيات فتح المكونات الإضافية للمحولات؟

أشعر أن المخاوف الأولية التي كانت موجودة طوال ذلك الوقت ، مثل نقص الوثائق حول واجهة برمجة التطبيقات ، والاضطرار إلى دعم تشابك رمز المستخدم <-> محولات <-> API ، لم تعد ذات صلة بعد الآن. لقد نجح دعم البرنامج المساعد المفتوح في إحداث عجائب لحزم مثل babel: التقدم من خلال التعاون. يمكنني أن أشهد شخصيًا على Babel على وجه التحديد ، بعد أن استخدمته على نطاق واسع.

أسهل تكامل "يعمل فقط" للمحولات مثل typecript -is _would_ be nice. أرى أن هذه الحزمة على وجه الخصوص تهدأ التأثير الثوري على المخطوطة المطبوعة ككل. عقود قوية حقيقية! 😃

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

* وفي هذه الأثناء يقوم شخص ما بإنشاء ميزة TS بدلاً من ذلك ( ttypescript ). لقد استخدمت هذا لتحقيق النجاح.

DanielRosenwasser لقد رأيت أن هناك "التحقيق في واجهات برمجة تطبيقات المكون الإضافي TypeScript" في خطة التكرار 3.5 (وقد بدأ هذا العمل عليها بالفعل).
هل تتناول هذه النقطة ما تمت مناقشته في هذه القضية؟ عدم وجود رابط لإحدى المشكلات يجعلني أفترض أن هناك الكثير من العمل قيد التقدم لمشاركة أي شيء بخصوصه حتى الآن؟

أعتقد أنه يجب وضع العمل على إضافة دعم كامل لمحلل Babel ، والذي يتضمن إضافة الميزات الضرورية لـ Babel لدعم التحليل الثابت لـ Typescript (على سبيل المثال ، تحويلات متعددة للملفات أو التبعية على ملفات متعددة أثناء التحويل). بدلاً من الاضطرار إلى تكرار بناء الجملة / تحويل ملحقات Babel إلى معادلات Bynscript.

في حال واجهتك أي مشكلة في التعليمات التالية ، أعلمني ، سأكون سعيدًا لمساعدتك

نظرًا للإهمال المطلق من فريق التصميم ، إليك الحل

سنستفيد من tslint وقدراته على إصلاح الكود

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

سنستخدم أدوات التزيين كعلامات للأماكن في الكود التي تحتاج إلى إعادة كتابتها

في حالتنا ، الديكور هو وظيفة وهمية هدفها الوحيد

• لتحديد مكان التحول
• وللتقاط النوع الذي سيكون مصدر المعلومات للمولد

لأغراض العرض ، سنقوم بتفريغ أسماء وأنواع خصائص الواجهة كسلاسل عادية ، في فئة أساسية

الخطوات التالية لمستخدمي الويندوز فقط ، إذا لم تكن منهم ، وفقكم الله:

1. ابدأ VSCode الخاص بك
2. قم بتثبيت الامتداد التالي: https://github.com/Microsoft/vscode-typescript-tslint-plugin
3. أغلق VSCode الخاص بك
4. انتقل إلى مجلد من اختيارك
5. تشغيل git clone https://github.com/zpdDG4gta8XKpMCd/code-gen.git
6. انتقل إلى المجلد code-gen : cd ./code-gen
7. يركض
   
   
   
   • 1-install.bat
   
   
   • 2-build.bat
   
   
   • 3-install-some-more.bat
   
   
   • 4-try.bat
   
   
8. لاحظ فتح مثيل VSCode
9. انتقل إلى test.ts ( Ctrl + P -> test.ts )
10. قم بتدوين الواجهة التالية ، وستكون مصدر منشئ الكود

interface Data {
    one: string;
    another: number;
}

1. قم بتدوين الوظيفة التالية ، والتي تشمل المصمم الوهمي الذي سنستخدمه كعلامة

function gen<_T>() {
    return function (meh: any) {};
}

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

@gen<Data>()
export class Gen {
}

1. لاحظ خطًا متعرجًا تحت @gen<Data>()
   

2. اختر Quick fix... -> Needs a rewrite, wanna fix?
   

3. لاحظ الكود الذي تم إنشاؤه تلقائيًا:
   

للإشارة هنا هو الكود المصدري للمولد الذي يمكنك العثور عليه في codeGenRule.ts

import * as Lint from 'tslint';
import * as ts from 'typescript';

export class Rule extends Lint.Rules.TypedRule {
    public applyWithProgram(sourceFile: ts.SourceFile, program: ts.Program): Lint.RuleFailure[] {
        return this.applyWithWalker(new Walker(sourceFile, this.getOptions(), program.getTypeChecker()));
    }
}

class Walker extends Lint.RuleWalker {
    constructor(sourceFile: ts.SourceFile, options: Lint.IOptions, private checker: ts.TypeChecker) {
        super(sourceFile, options);
    }
    public visitNode(node: ts.Node) {
        if (ts.isDecorator(node)) {
            const checked = check(node, this.checker);
            if (checked !== undefined) {
                const [node, message, replacement] = checked;
                this.addFailureAtNode(node, message, replacement);
            }
        }
        super.visitNode(node);
    }
}

function check(node: ts.Decorator, checker: ts.TypeChecker) {
    const { expression, parent } = node;
    if (!ts.isClassDeclaration(parent)) return;
    if (!ts.isCallExpression(expression)) return;
    const { expression: identifier, typeArguments: typeArgs } = expression;
    if (!ts.isIdentifier(identifier)) return;
    const { text: name } = identifier;
    if (name !== 'gen') return;
    if (typeArgs === undefined) return;
    if (typeArgs.length > 1) return;
    if (typeArgs.length < 1) return;
    const [only] = typeArgs;
    const type = checker.getTypeFromTypeNode(only);

    // if you got to here, you are at the right place and you have a type

    // working on a fix
    const properties = checker.getPropertiesOfType(type);
    const allNameTypes = properties.map(p => {
        const { name } = p
        const type = checker.getTypeOfSymbolAtLocation(p, node);
        return name + ': \'' + checker.typeToString(type) + '\';'
    })
    const { newLine } = ts.sys;
    const body = newLine + allNameTypes.join(newLine);
    const { pos: start, end } = parent.members;
    return [
        node,
        'Needs a rewrite, wanna fix?',
        Lint.Replacement.replaceFromTo(start, end, body)
    ] as const;
}

@ zpdDG4gta8XKpMCd ، شكرًا لمشاركة مفهومك - ولكن من فضلك كن متحضرًا.

نظرًا للإهمال المطلق من فريق التصميم ، إليك الحل

هذه ليست الطريقة المناسبة للتعامل مع TypeScript لعدم تنفيذ _ ميزة _ ترغب أنت (والعديد من الآخرين ، بما فيهم أنا) في الحصول عليها. هذا ليس عيبًا كبيرًا ولا يعكس "إهمالًا". من فضلك كن محترما.

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

أنتم أيها الناس لن تتوقفوا عن مفاجأتي

• ما تراه هو جزء من التعليمات البرمجية يبدو قادرًا على حل مشكلة كبيرة اليوم براحة (بدون حيل ، لا قرصنة)
• هذا الحل البديل هو دعوة للاستيقاظ لفريق التصميم ، وكما رأينا أنه يحدث من قبل عندما كان المجتمع على وشك اتخاذ منعطف في الاتجاه الخاطئ ، كان فريق التصميم موجودًا لمعالجة الأمر على الفور: # 4212 ،
• لذلك إذا كانوا مهتمين ، فيمكنهم القيام بذلك بشكل صحيح في وقت أقرب إلى أن يفوت الأوان ، أو إذا لم يفعلوا ذلك ، فنحن أحرار في الحفر في هذا الاتجاه ولن يكون ذلك مشكلة بالنسبة لهم في المستقبل
• لذلك كانت نبرة ملاحظاتي شيئًا غير مناسب ، ولكن كل النغمة المناسبة لك لم تحصل على شيء منذ 2 مارس 2017 (أكثر من عامين) ، ونعم ، يمكنك الانتظار لمدة عامين آخرين

@ zpdDG4gta8XKpMCd ما الذي ساهمت به في التنفيذ الفعلي؟ TypeScript مفتوح المصدر ؛ ليس لدي شك في أنهم سيفكرون بجدية في طلب سحب إذا أنشأت واحدًا (ولو جزئيًا).

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

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

أقترح عليك التوقف عن التعليق قبل أن يتم طردك من مستودع Microsoft بشكل دائم. أعرف ما إذا كان هذا هو الريبو الخاص بي ، فستكون في آخر قشة لك.

حسنًا ، لقد طردتني ، ثم ماذا
هل يمكنني العودة؟ ممكن انشاء حساب جديد؟
هل تعتقد أنني أهتم بهذا الحساب كثيرا؟

على أي حال ، نعم ، لقد حاولت سحب الطلبات ، ولكن للأسف لا يمكن ذلك للأسباب التالية:

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

2. نظرًا لأنه لا يمكنك حلها بمفردك ، فإن مشكلة كهذه (حتى مع وجود 224 إبهامًا) يمكن أن تنتظر سنوات إذا تم التفكير فيها على الإطلاق

3. لحسن الحظ ، يمكنك فعل شيء ما اليوم باستخدام أي وسيلة لديك والبدء في إحداث فرق يمكن رؤيته ، ومن هنا جاء الاقتراح (لا تلومني لأنني لم أفعل شيئًا)

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

Janpot Yup ، إنها حقًا قيد العمل قيد التقدم ، على الرغم من أنه عندما يعود rbuckton ، قد يكون قادرًا على تقديم المزيد من التفاصيل حول الحالة.

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

DanielRosenwasser ، ليس هناك الكثير من السخرية فيه ، لقد قلت كلمتين فقط ثم قلت إنني آسف بشدة لذلك

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

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

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

• لا يمكننا تنفيذ هذه الميزة بسبب A و BC وتلك التي تحتاج إلى D و E و F يتم تنفيذها أولاً

لذا أعتقد أنني أشير إلى هذه المحادثة: https://github.com/Microsoft/TypeScript/issues/30696#issuecomment -478799258

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

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

@ zpdDG4gta8XKpMCd لماذا تحتاج لإلقاء اللوم على شخص ما؟ لماذا لا تلوم نفسك في المقام الأول على أنك لم تقم بإجراء علاقات عامة لإصلاح هذه المشكلة؟ أو على الأقل بعض الكتابة البناءة حول كيفية التعامل معها من وجهة نظر التنفيذ؟

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

FredyC بحق الله ، انظر إلى الحل الخاص بي قبل أن أقول إنني لا أفعل أي شيء

نعم ، لا أقوم بتقديم طلبات سحب رسمية للأسباب التالية:

1. أنا لست على مستوى جيد

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

3. لن يتم حتى النظر في بعض المشكلات ، نظرًا لاعتبارات التصميم الكبرى التي لا يعرفها سوى عدد قليل من الأشخاص مثل Anders Hejlsberg

لا يمكنك إزالة جزء الإحباط ، ولست وحدي هنا

نحن نعلم أن هناك عوامل مؤثرة:

• التصميم الكبير للغة
• الميزانية / الموارد / السياسة داخل MS
• رغبات المجتمع

سأكون أكثر سعادة إذا كان اتخاذ القرار بمزيج هذه المكونات أكثر وضوحًا

لقد انتهيت ، لقد ذهب بعيدًا ، آسف لكل من تأذت مشاعره ، لن أقول كلمة واحدة

استمرار https://github.com/Microsoft/TypeScript/issues/14419#issuecomment -483920640

خيار آخر هو استخدام تعريفات الوظائف نفسها كعلامات ، ما يلي هو تنفيذ منشئ رمز للوظائف التي تبدأ أسماؤها بـ toRandom...

مصدر المعلومات للمولد هو نوع نتيجة الوظيفة

هذه هي الطريقة التي يعمل بها:

1. لاحظ الخط المتعرج تحت دالة تبدأ بـ toRandom...
   
2. اكتشف خياراتك:
   
3. قم بإصلاح سريع
   
4. لاحظ النتائج:
   

ها هو رمز codeGenRule.ts الذي يفعل ذلك

كمكافأة ، لن يؤدي هذا التنفيذ إلى إثارة مشكلة الفحص إلا إذا كان الكود الحالي للوظيفة لا يتطابق مع الكود الذي من المفترض أن يتم إنشاؤه

import * as Lint from 'tslint';
import * as ts from 'typescript';

export class Rule extends Lint.Rules.TypedRule {
    public applyWithProgram(sourceFile: ts.SourceFile, program: ts.Program): Lint.RuleFailure[] {
        return this.applyWithWalker(new Walker(sourceFile, this.getOptions(), program.getTypeChecker()));
    }
}

class Walker extends Lint.RuleWalker {
    constructor(sourceFile: ts.SourceFile, options: Lint.IOptions, private checker: ts.TypeChecker) {
        super(sourceFile, options);
    }
    public visitFunctionDeclaration(node: ts.FunctionDeclaration) {
        const checked = check(node, this.checker);
        if (checked !== undefined) {
            const [node, message, fix] = checked;
            this.addFailureAtNode(node, message, fix);
        }
        super.visitFunctionDeclaration(node);
    }
}

function check(node: ts.FunctionDeclaration, checker: ts.TypeChecker) {
    const { name: identifier, type: result, body } = node;
    if (body === undefined) return;
    if (identifier === undefined) return;
    const { text: name } = identifier;
    if (!name.startsWith('toRandom')) return;
    if (result === undefined) return;
    const type = checker.getTypeFromTypeNode(result);

    // if you got to here, you are at the right place and you have a type

    // working on a fix
    const properties = checker.getPropertiesOfType(type);
    const newerBody =
        `{
    return {${properties.map(prop => {
            const { name } = prop;
            const type = checker.getTypeOfSymbolAtLocation(prop, node);
            const typeName = capitalize(checker.typeToString(type));
            return `
        ${name}: toRandom${typeName}(),`;
        }).join('')}
    };
}`;
    const olderBody = body.getFullText();
    if (areEqual(olderBody, newerBody)) return;
    const start = body.getFullStart();
    const end = start + body.getFullWidth();
    return [
        node,
        'Needs a rewrite, wanna fix?',
        Lint.Replacement.replaceFromTo(start, end, newerBody),
    ] as const;
}

function areEqual(one: string, another: string) {
    // AB: we cannot make any assumption what line endings are,
    // this is why we compare the text of code without them
    return one.replace(/\r\n|\n/g, ' ') === another.replace(/\r\n|\n/g, ' ');
}

export function capitalize(value: string): string {
    const length = value.length;
    if (length > 1) {
        return value.substr(0, 1).toUpperCase() + value.substr(1);
    } else if (length > 0) {
        return value.substr(0, 1).toUpperCase();
    } else {
        return value;
    }
}

@ zpdDG4gta8XKpMCd أعتقد أن هذه المشكلة كانت تتعلق بطريقة أسهل لتوصيل المحولات المخصصة أثناء الإرسال؟ السابق. تحديد التحويلات في tsconfig.json بحيث يمكن استخدامها مع tsc بدلاً من استخدام API . هل تريد تغييرات / إصلاحات التعليمات البرمجية المخصصة في المحرر؟

لم أستخدمها على الإطلاق ، لكنني أعتقد أن ما تتحدث عنه قد يكون ممكنًا بالفعل مع مكون إضافي لخدمة اللغة (أعتقد أنه من خلال تجاوز getCodeFixesAtPosition في خدمة اللغة وإدخال إجراءات الكود الخاصة بك ... لست متأكدًا) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

أو ربما أنا سوء فهم؟

الصحيح. هذا بالضبط ما كنت أفكر فيه

اعتقدت أن طريقة تحديد تحويلاتي المخصصة عبر tsconfig.json ستكون بمثابة حلم يتحقق

ولكن بعد ذلك أدركت أنني أحب الحل البديل بشكل أفضل

هذا هو خط تفكيري:

• كنت بحاجة إلى مولد رمز شكلي قابل للتوصيل
• المطبوع عليه ليس لديه أي شيء من هذا القبيل في متناول يدي
• من ناحية أخرى ، أعلم أن tslint (على الرغم من إهماله بحلول نهاية عام 2019) هو عبارة عن نظام أساسي مناسب للمكوِّن الإضافي للطباعة وله طريقة للإضافة وتهيئة الكود الخاص بك بحرية كبيرة
• اتضح أنه يحتوي على كل ما أحتاجه:
  
  
  
  • قابل للتوصيل والتكوين
  
  
  • مع كل واجهة المستخدم اللازمة
  
  
  • يعطيني واجهة برمجة تطبيقات للطباعة
  
  
  • لديها القليل من الإضافات
  
  

بالنظر إلى كل ما لا أستطيع أن أرى نفسي أكتب شيئًا يستخدم خدمة اللغة المطبوعة ، للأسباب التالية:

• يمكن للكمبيوتر المحمول الخاص بي أن يحتوي فقط على العديد من خدمات اللغة المطبوعة ، وبعضها بالفعل:
  
  
  
  • واحد من vscode
  
  
  • واحد من tslint
  
  

ولا أريد إضافة واحدة أخرى فوق ذلك

أتمنى لو كان لدي طريقة أفضل لتوصيل محولات الكود الخاصة بي ، لكن لدينا ما لدينا

وهذه هي طريقة عملنا لوحدات الماكرو: # 4892

• يمكن للكمبيوتر المحمول الخاص بي أن يحتوي فقط على العديد من خدمات اللغة المطبوعة ، وبعضها بالفعل:

  • واحد من vscode
  • واحد من tslint

@ zpdDG4gta8XKpMCd أعتقد أن كل شيء يجب أن يستخدم نفس خدمة اللغة. لذلك سيكون لديك خدمة لغة واحدة ومن ثم سيقوم المكون الإضافي tslint مع المكون الإضافي الخاص بك بالوكالة عن ذلك.

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

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

شكرا لك على المدخلات القيمة ، سوف أعتبرها

لا أتفق معك في الاحتفاظ بالمحادثة فقط حول المحولات المخصصة كجزء من الإنشاء بـ tsc ، منذ ذلك الحين

• الطلب الأصلي كما هو مكتوب ليس محددًا في أي شكل يتحول ليتم تسليمه ، فهو ينص فقط على أنه لا ينبغي أن يتطلب ذلك
  > قم بتكرار سطر أوامر tsc بالكامل فقط لإضافة محول واحد
• على مدار عامين ، جذبت هذه المناقشة قدرًا كبيرًا من الاهتمام من العديد من الأشخاص الذين لا يبدو أنهم يهتمون كثيرًا بكيفية تنفيذ المحولات ، بشرط أن يكون هناك حل ، ويعمل وسهل الاستخدام
• أيضًا ، قام فريق tslint بعمل جيد في بناء البنية التحتية للمكونات الإضافية ، فعدم استخدامه يعد مضيعة للجهد ، بشرط أن يكون بحكم الواقع النظام الأساسي الوحيد المعترف به رسميًا خارج الكتابة المطبوعة التي تتعامل مع الكتابة المطبوعة
• أيضًا ، نتفق جميعًا على أنه حتى لو وجدت المحولات طريقها إلى اللغة ، فلن يحدث ذلك في أي وقت قريب ، لكن الناس هنا (بمن فيهم أنا) احتاجوها مثل الأمس
• أخيرًا ، نظرًا لعدم وجود العديد من البدائل الأفضل ، فلماذا لا نفكر على الأقل فيما لدينا؟

تم تصنيف اقتراحي بوضوح على أنه حل بديل (بينما يأخذ فريق التصميم وقتهم في التفكير بجدية أكبر في حل مناسب) ، فلماذا لا؟

إذا كنت تصر على أننا يجب أن نفعل ذلك في مكان آخر ، يرجى التحدث

ولكن لمعالجة قلقك الشديد من القيام بـ

تحويل عبر مشروع بأكمله

يقوم tslint بهذا الأمر تمامًا باستخدام الوسيطة --fix الخاصة بـ cli

@ zpdDG4gta8XKpMCd --fix سيقوم بتحديث كود TypeScript في مكانه. تتعلق هذه المشكلة بإجراء تحويلات أثناء الإرسال (بحيث تنتهي التغييرات فقط في ملفات JavaScript النهائية). انظر العلاقات العامة للمشكلة المشار إليها (# 13940):

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

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

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

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

انت غامض

أنا شخص يفهم ويقدر الأشياء البسيطة

مشكلتي هي أنني أتعامل مع حوالي 3500+ مشروع ملف ، 15٪ منها لا تحتاج إلى كتابتها باليد وصيانتها وهناك حوالي 5٪ من الأشياء المماثلة فوقها في المستقبل

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

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

بعض الناس الذين جاءوا إلى هنا سيناقشون بعض الأمور الدقيقة

حسنًا ، رائع!

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

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

نعمل حاليًا على تطوير إطار عمل ونستخدم حاليًا ttypescript من أجل الوصول إلى معلومات على مستوى النوع في وقت التشغيل ، سيكون من الجيد أن يكون لديك الخيار plugins في المترجم الرسمي في النهاية 😄

أنا في إجازة الآن لكني سأبحث الأسبوع المقبل عندما أعود

يوم الأحد 21 يوليو 2019 الساعة 5:54 مساءً Giorgio Boa [email protected]
كتب:

longlho https://github.com/longlho لقد صنعت الكثير من الأشياء الرائعة
محولات ، أحتاج مساعدتكم 👍
أود حقًا تعديل البيانات الوصفية لمصمم الديكور قبل النشر الزاوي.
هدفي هو تعديل هذه العقدة
المكون ({selector: 'standard' ...}) في المكون ({selector: 'custom'
...})
لقد صنعت مستودع جيثب لاختباره
https://github.com/gioboa/ng-ts-transformer . أعتقد أنه من الممكن ولكن
بدون وثائق أحتاج إلى بعض المساعدة. 🙏 شكرا.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/TypeScript/issues/14419؟email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVB86
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
.

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

أود حقًا أن أرى هذه الميزة تحدث. أنا متأكد من أن هذا هو الشيء الوحيد الذي يقف بين Typescript وبعض الابتكارات العظيمة التي قد تؤدي إليها.

تعد الكتابة المطبوعة مساهمة كبيرة في تطوير الواجهة الأمامية ، ولكن لها أيضًا مكابح أمام المزيد من الابتكارات ...
لا تكسر الدلالات. لا توجد أداة ATM إضافية لا يمكنها كسر الدلالات ؛ ولا يُسمح بأي مكونات إضافية على الإطلاق: man_shrugging: لماذا؟
هناك بالفعل مكونات إضافية جيدة ، ولكن. يجب أن يحترم كل مكون إضافي (مفتاح) ترميز الكلمة وتأسيس AST) ... ، طريقة صعبة حقًا للقيام بشيء ما بداخله.
ليس الأمر صعبًا. إنه ليس بالأمر السهل ، لكن مشروع بابل يوضح أنه ممكن.
في الواقع ، يكاد يكون من التافه أن يقدم بابل دلالات جديدة أو حتى عبارات نحوية.

لا أتوقع من الكتابة المطبوعة للسماح بدلالات. (كما أنني لا أتوقع تغييرات في بناء الجملة بالطبع!)
ما أتمناه هو التحول في بعض الحالات ، مثل (قد يكون نوعًا فقط) preeval.
كما لو كان لدي وظيفة take ، مثل route أو message أو شيء من هذا القبيل ، يمكن للمترجم أن يقوم بالتقييم المسبق و (أوه ، من فضلك ، في المرحلة الأولى) يتحقق من صحتها.

إذا كنت تقرأ فقرتي السابقة غريب. ما هو tsx وكل ما هو رد فعل الخير؟

لا يوجد رد فعل ، لا تدفق ، لا يوجد نص مطبوع على الإطلاق ، تقريبًا ليس للوهلة الأولى.

لو سمحت. أنا أفهم جيدًا النظر بعناية في كل هذا ؛ ولكن كما نتعلم من IE5.5 + ؛ الحجب ليس وسيلة للمضي قدما.

إذا كان هناك شيء يحتاج إلى تحسين ، فلا يزال محرك التخطيط. كان D.Knuth جيني الذي صمم جميع الأجزاء المفقودة منذ 50 عامًا. لماذا ليس لدينا هذا اليوم ؟؟ :-)
من فضلك ، قل للناس لوقف CSS في JS evilness.

لو سمحت. فتح TS للذكاء الدلالي ؛ مثل الوظيفة مع إدخال سلسلة ثابتة ، مما يوفر تلميحًا للنوع للباقي ؛ تحليل سلسلة إدخال const الفعلية ...
مثال بسيط:

• شكل إرجاع استدعاء GraphQL
• شكل الإدخال الدولي
• …أكثر بكثير_
  لو سمحت. لا حاجة لتغييرات في الدلالات. كل شيء سيعمل حسب الرغبة. قد يتم التحقق من شيء أكثر في وقت الإنشاء. هذا كل ما لدي أيها الناس! :أرنب:

صدم

أنا أجرب كتابة تحويلات TS للتحسين core-js import - ملء تلقائي للبيئات المستهدفة ، مثل @babel/preset-env و @babel/runtime ، لكن بدون babel . يمكن أن يساعد بجدية جزء كبير من مطوري TS. ولكن بدون دعم التحويلات المخصصة من الصندوق بدون أدوات إضافية مثل ttypescript ، ستكون إمكانية استخدام هذه التحويلات محدودة للغاية ، لذلك لست متأكدًا من أن ذلك منطقي.

لقد جربت هذه الفكرة - https://github.com/webschik/typescript-polyfills-generator.
أعتقد أن Transformers API ستفتح إمكانية لإسقاط babel من سلسلة التطوير. أعتقد أن الكثير من المطورين لا يريدون استخدام كلاهما ، لكنهم ما زالوا بحاجة إلى مكونات إضافية مثل @babel/preset-env .

لقد قمنا حاليًا بتدوير برنامج التحويل البرمجي المخصص الخاص بنا (باستخدام واجهة برمجة تطبيقات التحويل البرمجي TypeScript) بسبب هذا القيد. نظرنا بإيجاز إلى ttypescript ، لكن الرغبة في الابتعاد عن مترجم Vanilla TypeScript إلى امتداد مترجم TypeScript ليست موجودة.

سيكون من الرائع لو تم دعم المحولات المخصصة في tsconfig.json. من الصعب كتابة نص يقوم ببساطة بتحليل tsconfig ، ويعلن عن المحولات ، ثم يقوم بتشغيل المترجم ؛ أو الأسوأ من ذلك محاولة ومحاولة إعادة تنفيذ الميزات الأساسية للمجمع ، مثل مشاهدة الملفات ، في نص مخصص.

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

مثال على النظام البيئي الإضافي الناجح للغاية هو مجتمع المكون الإضافي لـ Serverless Framework. لا يستطيع فريق التطوير مواكبة الطلب على تطوير الميزات ، وتتيح المكونات الإضافية طريقة رائعة للسماح بدمج ميزات جديدة (ربما تجريبية) دون الحاجة إلى فتح علاقات عامة أو تقليل المنتج الأساسي بميزات قد أو قد لا تقدم قيمة لقاعدة أوسع من المستخدمين.

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

من أجل جعل TypeScript يدعم المحولات المخصصة بدون برامج مجمعة وتعليمات معقدة ، قمت بكتابة أداة تسمى ts-patch ( npm github )

ما عليك سوى تثبيت ts-patch (عالميًا أو محليًا) وتشغيل ts-patch install لتصحيح الكتابة المطبوعة. يمكنك أيضًا تحديد دليل التثبيت المطبوع عليه و / أو تمكين استمرار ، والذي يحافظ على التصحيح إذا تم تحديث TS أو إعادة تثبيته. (التفاصيل: ts-patch /? )

يعتمد منطق التصحيح في الغالب على ttypescript. (شكراً جزيلاً لعمل cevek الرائع!) لقد تمت كتابته بطريقة يمكن بسهولة إضافتها إلى عملية تثبيت حزمة npm. من السهل أيضًا إلغاء التصحيح.

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

آمل أن يساعد هذا بعض الناس!

من أجل جعل TypeScript يدعم المحولات المخصصة بدون برامج مجمعة وتعليمات معقدة ، قمت بكتابة أداة تسمى ts-patch ( npm github )

ما عليك سوى تثبيت ts-patch (عالميًا أو محليًا) وتشغيل ts-patch install لتصحيح الكتابة المطبوعة. يمكنك أيضًا تحديد دليل التثبيت المطبوع عليه و / أو تمكين استمرار ، والذي يحافظ على التصحيح إذا تم تحديث TS أو إعادة تثبيته. (التفاصيل: ts-patch /? )

يعتمد منطق التصحيح في الغالب على ttypescript. (شكراً جزيلاً لعمل cevek الرائع!) لقد تمت كتابته بطريقة يمكن بسهولة إضافتها إلى عملية تثبيت حزمة npm. من السهل أيضًا إلغاء التصحيح.

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

آمل أن يساعد هذا بعض الناس!

هل يمكن رفع هذا باعتباره علاقات عامة لإضافة / مناقشة الدعم المناسب؟ :)

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

https://github.com/fuse-box/fuse-box/blob/master/docs/plugins/pluginCustomTransform.md

هل يمكن رفع هذا باعتباره علاقات عامة لإضافة / مناقشة الدعم المناسب؟ :)

أعرب فريق TS عن عدم رغبتهم في تقديم هذا كميزة أصلية. أسباب اتخاذ القرار منطقية!

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

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

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

بعد كتابة ملحق يمكنني أن أقدر سبب تردد فريق ts - المحول الحالي هو خطوة ما بعد التجميع. ستواجه مشكلات سيئة إذا فعلت شيئًا معقدًا وبدأت في إضافة محتوى جديد لم يكن ملزمًا في الأصل. كما هو الحال ، ts-node --compiler ttypescript foo.ts يعمل بشكل جيد تمامًا. أفضل أن يتعامل فريق ts مع إضافات المحولات في خطوات تجميع مختلفة ... أو السماح بخطوة إعادة ربط.

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

يمكن تشغيل المحولات إما قبل أو بعد تجميع TSC. يبدو أن ما تشير إليه هو أن المدقق لا يتم تحديثه بعد تعديل العقد. يمكن التحايل على هذا في الواقع ، لم يتم إنشاء الوظيفة من أجله. عندما تستدعي ts.transform () ، لا يُنشئ مثيل برنامج كامل لتعمل معه ، لذلك إذا كنت تريد العمل مع المدقق ، فأنت بحاجة إلى إنشاء مثيل. باستخدام CompilerHost ، يمكنك إعادة تحميله بالملفات المعدلة بعد تعديل AST.

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

nonara لقد استخدمت تحويلات مع ttypescript و ts-loader` ، كلاهما لهما نقاط دخول كاملة للبرنامج. مشكلتي هي أنك إذا أضفت بيان استيراد جديد ، فسيتم تجريد "شيء" مفقود وتلك العبارات الجديدة من إخراج الإخراج النهائي. weswigham يقول ذلك لأن التحويل هو خطوة ما بعد الربط . يبدو أن الحل هو إنشاء برنامج جديد تمامًا للملف - ولكن هذا يبدو وكأنه صداع عندما تتعامل مع أشياء مثل ts-loader (خاصةً عندما يكون في وضع التحويل فقط ويخفي ملف webpack / bundler تمامًا- محلل. في النهاية أسقطت الاستيراد وأضفت للتو الرمز الذي أحتاجه .

MeirionHughes آه ، حسنًا. في هذه الحالة ، نعم ، لديك مثيل البرنامج. يعمل ttypescript عن طريق ربط createProgram لتصحيح طريقة إرسال program الناتجة لتضمين المحولات.

• ts.emitFiles calls ts.transformNodes أثناء العملية.
• يمكن استدعاء ts.transformNodes مع مثيل البرنامج أو بدونه. الاتصال المباشر بـ ts.transform() يفعل ذلك بدون واحد.

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

مرحبًا بالجميع الذين كنت أكتب كتيب Transformer Handbook لتجميع جميع المعلومات حول المحولات وكذلك لتسهيل البدء.

https://github.com/madou/ts-transformer-handbook/blob/master/translations/en/transformer-handbook.md

أحب بعض العيون عليه إذا كان بإمكانك توفير ثانية

madou كتبت أيضًا منشورات buncha على محولات TS https://levelup.gitconnected.com/writing-typescript-custom-ast-transformer-part-1-7585d6916819

ما هو الوضع على هذا؟

أحب الكتابة المطبوعة كثيرًا ، لكنها تشعر بالضيق بشكل خاص عندما تبدأ في التداخل بين الأنواع الثابتة ووقت تشغيل JS. هناك العديد من المكونات الإضافية المكتوبة من المجتمع لتحسين ذلك ، على سبيل المثال https://github.com/dsherret/ts-nameof ، https://github.com/kimamula/ts-transformer-keys - ولكن بدون دعم المكون الإضافي من الدرجة الأولى يبدو الأمر وكأنه قرار تقني محفوف بالمخاطر لإدراجهم في المشروع. سيسمح تمكين المكونات الإضافية محليًا للمجتمع بالتجول مع ميزات الكتابة المطبوعة المستقبلية المحتملة ، قبل الحاجة إلى تضمينها في المكتبة الأساسية.

أعتقد أن فريق TypeScript يجب أن يعيد النظر في حججهم. يعد النظام البيئي للمكون الإضافي طريقة مثبتة لتحريك اللغة إلى الأمام ، وتمكين (وتشجيع) التجارب (انظر Haskell مع براغماتها).

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

بشكل عام ، يبدو موقف فريق TypeScript صارمًا بشكل غير ضروري.

هناك أيضًا تحويلات لا تغير اللغة ولكنها توفر معلومات إضافية لتصحيح الأخطاء بشكل أسهل.

على سبيل المثال ، يعد babel-plugin-transform-response-jsx-source جزءًا من الإعداد المسبق لترحيل التفاعل الافتراضي ( @ babel / preset- reaction).
يتحول

<sometag />

إلى

<sometag __source={ { fileName: 'this/file.js', lineNumber: 10 } } />

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

بالنسبة للطباعة المطبوعة ، لا توجد طريقة قياسية لتحقيق ذلك على الرغم من وجود تحويل مفتوح المصدر: https://github.com/dropbox/ts-transform-react-jsx-source

أفهم أن mhegazy قد ذكر مرتين أن فريق TS ليس لديه خطة لتضمين "المكونات الإضافية" كجزء من tsconfig. ما السبب خلف هذا؟

هل ستكون منفتحًا على العلاقات العامة؟ الطريقة التي يتعامل بها ttypescript مع المحولات عبر tsconfig رائعة جدًا.

استخدم حالات:

1) إنشاء أنواع واجهة للمخططات بحيث يمكن التحقق من وقت التشغيل.
2) استيراد json بسلاسل نصية كأحرف حرفية ، لذا فإن الكتابة المطبوعة لا تتعارض عند تعيينها إلى نوع به اتحادات مميزة.
3) استيراد css / yaml وكائنات أخرى مثل بناء الجملة
4) عمل استعلامات Graphql التي تنشئ الأنواع الصحيحة ديناميكيًا
5) ترجمة jsx إلى سلاسل html بحيث يمكن إدخالها داخل HTML
5) إعادة كتابة الواردات المطلقة إلى الواردات النسبية بناءً على مسارات tsconfig.

والقائمة تطول وتطول. البرنامج المساعد api لطيف. شكرا للهبوط عليه. إن وجود جزء من "الإضافات" من "tsconfig" يجعل tsc قويًا حقًا. هل هناك شيء كبير نفتقده؟

يمكنك أيضًا إجراء الكثير من تحسينات الأداء. لقد كنت أكتب https://github.com/atlassian-labs/compiled-css-in-js باستخدام محولات مطبوعة سيكون رائعًا إذا لم يكن المستهلكون بحاجة إلى القفز من خلال الأطواق لاستخدامه بالرغم من ذلك.

عزيزي فريق Typescript ، يرجى التوقف عن جر كعبيك على هذا <_ <

ما هو الوضع على هذا؟

حالة؟

أصدقاء ما الأخبار؟

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

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

ولكن ماذا لو أردت بعض الاختراقات لفحص النوع؟ أكتب محولًا صغيرًا يصنع بعض السحر:

type Human = {
    name: string,
    age: number
}

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true
const isValid = check<Human>({ name: 'Carl' }) // => false

الوظيفة check تحولت إلى وظيفة حراسة محددة! كيف يمكنني عمل ذلك مع بابل؟ حاليًا ، يجب أن أستخدم ttypescript ...

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

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

ولكن لتسهيل الأمر ، يمكنك استخدام ttypescript أو ts-patch .

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

@ ilya-buligin إذا فهمت حالة الاستخدام الخاصة بك بشكل صحيح ، فيمكنك إعلان ثابت محيط

declare const check: <T>(value: unknown) => value is T;

const isValid = check<Human>({ name: 'Carl', age: 16 }) // => true

سوف يُجمّع Typescript الكود بالاعتماد على تعريف النوع check وبعد ذلك ستستبدله بكود تم إنشاؤه باستخدام Babel.

@ just-boris كيف يمكنني الوصول إلى النوع العام <T> في Babel؟

هذا الموضوع أصبح متكررًا إلى حد ما وبعيدًا عن الموضوع. RyanCavanaugh ربما يجب قفل هذا الموضوع حتى يكون لديك أي تحديثات حول هذا الموضوع.