Typescript: कस्टम ट्रांसफॉर्मर के लिए प्लगइन समर्थन

हम अल्पावधि में कंपाइलर प्लगइन सिस्टम को उजागर करने की योजना नहीं बनाते हैं। जैसा कि आपने नोट किया है, सार्वजनिक एपीआई के हिस्से के रूप में ट्रांसफॉर्म का खुलासा किया गया है, और हम इनके लिए दस्तावेज और नमूने लिखने की प्रक्रिया में हैं।

मैं एक खुला प्लगइन एपीआई नहीं चाहता। इसके बजाय, मैं टीएस-कंपाइलर एपीआई का उपयोग करने के बजाय tsconfig.json में उन्हें निर्दिष्ट करके अपने कस्टम ट्रांसफॉर्म को पंजीकृत करने का तरीका पसंद करूंगा। क्योंकि टीएस-कंपाइलर एपीआई का उपयोग करने का तात्पर्य है कि मैं अब tsc कमांड लाइन टूल का उपयोग नहीं कर सकता, जिसका अर्थ यह हो सकता है कि यह अब मौजूदा बिल्ड टूल्स और वर्कफ़्लो में अच्छी तरह से एकीकृत नहीं है।

दस्तावेज़ीकरण और नमूने के बारे में कुछ भी अद्यतन? @mhegazy

@MichaReiser आप एपीआई के आधार पर एक साधारण कंपाइलर लिख सकते हैं (नमूना यहां )। हम वास्तव में याहू फाइनेंस के भीतर टीएस का बहुत अधिक उपयोग करते हैं और ट्रांसफॉर्मर पब्लिक एपीआई कमाल का रहा है।

वे कुछ ट्रांसफॉर्मर हैं जिन्हें हमने सार्वजनिक होने के बाद लिखा था:
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 अगर आपको दस्तावेज़ीकरण/नमूने इकट्ठा करने में मदद की ज़रूरत है

@longlho
आपके नमूने के लिए धन्यवाद।

मैं वर्तमान में यही कर रहा हूं। हालांकि, टाइपस्क्रिप्ट के लिए बनाए गए अन्य बिल्ड टूल्स का उपयोग करना असंभव बनाता है, जैसे वेब पैक लोडर, जेस्ट लोडर। इसके अलावा, जब हम में से प्रत्येक एक अलग फ़्रंटएंड का उपयोग करता है, तो मैं अपने प्लगइन्स में से एक का उपयोग कैसे कर सकता हूं?

इसलिए, मेरा मानना ​​है कि वर्तमान दृष्टिकोण एक अच्छी शुरुआत है लेकिन प्लगइन पारिस्थितिकी तंत्र के लिए पर्याप्त नहीं है। क्योंकि प्लगइन का उपयोग करना उपयोगकर्ता के लिए बहुत अधिक प्रयास है और इसके लिए लेखक के लिए केवल रूपांतरण कोड लिखने से अधिक की आवश्यकता होती है।

मेरा मानना ​​​​है कि यदि लक्ष्य समुदाय को कस्टम ट्रांसफार्मर बनाने और उपयोग करने के लिए प्रोत्साहित करना है, तो टाइपस्क्रिप्ट के लिए बैबेल की तरह एक प्लगइन सिस्टम आवश्यक है।

@MichaReiser हाँ। मैं यह नहीं कह रहा हूं कि यह पारिस्थितिकी तंत्र के लिए पर्याप्त है, इसके लिए पहले चरण के लिए पर्याप्त है।

मैं गल्प-टाइपस्क्रिप्ट में परिवर्तन के लिए समर्थन जोड़ना चाहता हूं, लेकिन मैं यह रोकना चाहता हूं कि सभी टाइपस्क्रिप्ट प्लगइन्स (गल्प, वेबपैक आदि के लिए) एक अलग एपीआई का प्रस्ताव करते हैं। और टाइपस्क्रिप्ट इसे बाद में कॉन्फ़िगर करने के लिए एक अलग तरीका भी जोड़ सकता है। तो क्या आपके पास वर्तमान में निकट या दूर भविष्य में इसे जोड़ने की योजना है?

हाय सब, मैं एक प्रीप्रोसेसर लिखने की कोशिश करता हूं, लेकिन कुछ भी नहीं निकलता है :[

वास्तव में, मेरे दो प्रश्न हैं:

• स्ट्रिंग से एएसटी-टुकड़ा कैसे बनाएं?
• आयात कैसे जोड़ें?

// 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 आयात करता है पूरे मॉड्यूल ऑब्जेक्ट के बजाय

हाँ, हम अपने CSS मॉड्यूल ट्रांसफॉर्मर में import * as foo कर रहे हैं और साथ ही अलियासिंग को रोकने के लिए। हालांकि कुछ नामित निर्यातों को इनलाइन करने के लिए उसमें टैप करना अच्छा होगा

@rbuckton ओ, बहुत बहुत धन्यवाद!
अभी भी दिलचस्पी है कि स्ट्रिंग से मनमाना एएसटी-टुकड़ा कैसे बनाया जाए?

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;
}

यह वही है जो मैं उम्मीद कर रहा था कि ट्रांसफॉर्मर सपोर्ट और वर्कफ़्लो टाइपस्क्रिप्ट की तरह व्यवहार करेगा।

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 रिलीज में या कम से कम रोडमैप में किसी बिंदु पर उतर सकता है, @ahejlsberg @mhegazy @DanielRosenwasser आप क्या सोचते हैं? इस तरह कस्टम ट्रांसफॉर्मर अधिक लोकप्रिय और इसलिए अधिक शक्तिशाली हो सकते हैं। Tsconfig.json के नजरिए से ट्रांसफ्रोमर में प्लग इन करने का विकल्प होने से जीवन बहुत सरल हो जाएगा।

जैसा कि पहले उल्लेख किया गया है, हमारी अल्पावधि में प्लगइन्स को उजागर करने की कोई योजना नहीं है।

@mhegazy क्या यह एक सुविचारित निर्णय है या कम सामुदायिक हित के कारण यह दायरे से बाहर है?

मैंने वैसा नहीं कहा। हम एक छोटी सार्वजनिक एपीआई/रखरखाव लागत के साथ-साथ निर्माण को आगे बढ़ने के तरीके को बदलने में लचीलापन बनाए रखना चाहते हैं, और ये दोनों प्लगइन मॉडल से प्रभावित होते हैं।

कृपया, ट्रांसफॉर्मर प्लगइन एपीआई विखंडन बंद करो। ट्रांसफोमर एपीआई के शीर्ष पर प्लगइन एपीआई को स्थिर करें और उन्हें tsconfig.json में बेनकाब करें।

टीएस-लोडर , पार्सल-प्लगइन-टाइपस्क्रिप्ट , रोलअप-प्लगइन-टाइपस्क्रिप्ट 2, टीएस-ट्रांसफॉर्मर-की , टीटाइपस्क्रिप्ट और अन्य।

उनमें से प्रत्येक कस्टम प्लगइन पंजीकरण विधि और कस्टम प्लगइन प्रविष्टि बिंदु प्रारूप प्रदान करता है। यह ts प्लगइन नरक का एक तरीका है।

अब cevec/ttypescript सभी सामान्य ट्रांसफॉर्मर प्लगइन स्वरूपों का समर्थन करता है। यह सभी टाइपस्क्रिप्ट मॉड्यूल और tsc, tsserver कमांड (बस छोटा रनटाइम ts.createProgram पैच) के शीर्ष पर एक ड्रॉप-इन रैपर है। वेबपैक ts-loader और रोलअप-प्लगइन-टाइपस्क्रिप्ट2 को 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/**/*"]
}

इस पर कोई खबर? मुझे ऐसा लगता है कि टाइपस्क्रिप्ट लेखक किसी तरह वैनिला टाइपस्क्रिप्ट पर कस्टम ट्रांसफॉर्मर की अनुमति नहीं देना चाहते हैं - यह शर्म की बात है, यह एक कमाल की विशेषता होगी।

वे नहीं चाहते हैं कि आंतरिक में चीजों को तोड़ने में कठिनाई होने के डर से एक और एपीआई/सतह बनाए रखा जाए। विडंबना यह है कि ये सभी तृतीय-पक्ष प्लगइन समाधान हैं, क्योंकि टीएस-टीम द्वारा कोई मानक नहीं है, सभी कुछ अलग हैं और अंततः टूट जाएंगे।

वे नहीं चाहते हैं कि आंतरिक में चीजों को तोड़ने में कठिनाई होने के डर से एक और एपीआई/सतह बनाए रखा जाए।

टाइपस्क्रिप्ट के साथ काम करने और इसके विकास को देखने के 3 साल बाद, मैं एक साधारण निष्कर्ष पर आया हूं। Microsoft के पास _code_ के अर्थ में ओपन-सोर्स टाइपस्क्रिप्ट है, लेकिन _process_ के अर्थ में नहीं। अधिकांश मामलों में, ओपन-सोर्स प्रोजेक्ट निर्णय और कोडिंग दोनों में कमोबेश समुदाय-संचालित होते हैं, और यह विकसित होने का स्वाभाविक तरीका होना चाहिए। क्या आपको node.js का IO.js कांटा याद है? समुदाय ने महसूस किया कि कंपनी के हित सामान्य ओपन सोर्स गवर्नेंस मॉडल के साथ इतने संरेखित नहीं थे, और उन्होंने बस फोर्क किया। मुझे आशा है कि टाइपस्क्रिप्ट के लिए ऐसा नहीं होगा, लेकिन Microsoft को इस संभावना को ध्यान में रखना चाहिए।
स्पष्ट होने के लिए, मैं देवों को दोष नहीं दे रहा हूं, वैसे भी, वे वास्तव में बहुत अच्छा काम करते हैं।
बस मेरा 2c, OT के लिए खेद है।

Microsoft के पास कोड के अर्थ में ओपन-सोर्स टाइपस्क्रिप्ट है, लेकिन प्रक्रिया के अर्थ में नहीं।

मैं इस बात से पूरी तरह असहमत हूं। मैंने माइक्रोसॉफ्ट के लिए कभी काम नहीं किया है, लेकिन पिछले 4 वर्षों में टाइपस्क्रिप्ट की कई विशेषताओं पर मेरा सीधा प्रभाव पड़ा है। मैं टाइपस्क्रिप्ट में निर्मित एक ओपन सोर्स लाइब्रेरी का प्रतिनिधित्व कर रहा था, और हमने कुछ सीधी बातचीत की व्यवस्था की, लेकिन किसी भी फीचर की सभी "बहस" सार्वजनिक रूप से, यहां खुली हुई थी। कोर टीम अपने डिजाइन मीटिंग नोट्स प्रकाशित करती है। एक ओपन सोर्स लाइब्रेरी का प्रतिनिधित्व करने वाला एकमात्र "अंदरूनी सूत्र" मुझे व्यक्तिगत रूप से कुछ विशेषताओं के लिए अपने मामले पर बहस करने और कोर टीम से मिलने का अवसर मिला। इससे मुझे एहसास हुआ कि टीम एक टीम के रूप में काम करती है। एक विशेषता जिसके बारे में हमने बात की, एंडर्स ने मूल रूप से कहा कि समस्या बहुत कठिन थी और इसे दूर करने और लोगों द्वारा सामना की जाने वाली "वास्तविक" समस्याओं को हल करने में बहुत समय लगेगा। वह दो साल पहले था और टाइपस्क्रिप्ट 3.0 में हम अंत में इसे प्राप्त करते हैं। लेकिन डिजाइन प्रक्रिया में समुदाय की आवाज होती है, लेकिन किसी भी समुदाय की तरह, हमने अलग-अलग आवाजें उठाई हैं, और कोई भी टीम कहीं भी सभी को खुश नहीं कर सकती है, और अगर उन्होंने ऐसा किया, तो टाइपस्क्रिप्ट एक _असली_ खराब टूल होगा।

आप कोर टीम को "माइक्रोसॉफ्ट" भी लेबल करना चाहते हैं। कोर टीम सबसे कम Microsoft टीम थी जिसका मैंने अब तक सामना किया है। अपनी रिलीज़ सामग्री के पूर्ण नियंत्रण पर स्थापित होने के बाद, उन्होंने अपनी रिलीज़ ताल पर पूर्ण नियंत्रण पाने के लिए लड़ाई लड़ी। उन्होंने खुलेपन और पारदर्शिता के लिए भी लड़ाई लड़ी। कोडप्लेक्स से गिटहब में जाने के लिए संघर्ष किया। माना जाता है कि वे अब माइक्रोसॉफ्ट में उतने अद्वितीय नहीं हैं क्योंकि कई अन्य टीमों ने अपना मॉडल अपनाया है, लेकिन जहां तक ​​​​मुझे पता है, वे ही थे, जिन्होंने वीएससीओडी टीम के साथ जल्दी से बाद में इसे शुरू किया था।

इसलिए सिर्फ इसलिए कि कोर टीम अपनी लड़ाई चुनती है और अपने डिजाइन सिद्धांतों पर टिकी रहती है, इसका मतलब यह नहीं है कि समुदाय के पास आवाज नहीं है, लेकिन एक आवाज के रूप में हम मानसिक बहु व्यक्तित्व विकार से पीड़ित हैं। हम सेवा करने के लिए एक कठिन ग्राहक हैं।

मेरी समझ यह है कि यह #16607 जैसा ही है, या यह एक अलग लक्ष्य प्राप्त करेगा? हाल ही में एक प्लगइन-लेखक के रूप में, मैं इसे उजागर करना भी चाहता हूं - जिसमें बैबेल प्लगइन का उपयोग करके टाइपस्क्रिप्ट के साथ काम करना शामिल है।

@mrmckeb यह मुद्दा टाइपस्क्रिप्ट एएसटी परिवर्तन को मानकीकृत और उजागर करने के लिए है, जो पहले से मौजूद है, जबकि जुड़ा हुआ मुद्दा पूरे फ़ाइल परिवर्तन पर एक बहुत व्यापक (अपरिभाषित) दायरे में चर्चा कर रहा है।

मैं यहां अपने 2 सेंट जोड़ना चाहता हूं। आप में से कुछ लोगों ने शानदार प्रोजेक्ट बैबेल-प्लगइन-मैक्रोज़ के बारे में सुना होगा। मूल रूप से, हजारों अलग-अलग बैबेल प्लगइन्स होने के बजाय, केवल एक ही हो सकता है जो एक परिवर्तन करने के लिए उपयोगकर्ता कोड द्वारा संचालित होता है। हर समय कॉन्फ़िगरेशन के साथ खिलवाड़ करने की आवश्यकता के बिना एक अद्भुत पारदर्शी प्रणाली। यह सीआरए जैसी परियोजनाओं के लिए विशेष रूप से बढ़िया है जो मैक्रोज़ का समर्थन करता है लेकिन अतिरिक्त कॉन्फ़िगरेशन को मना करता है।

आज मैंने इस पर चर्चा शुरू की है कि इसे टाइपस्क्रिप्ट की दुनिया में कैसे लाया जा सकता है। अगर आपके पास कुछ अंतर्दृष्टि है, तो कृपया आएं और साझा करें।

अंत में, मुझे आशा है कि अगर हम किसी तरह सफल होते हैं, तो इसकी कोई आवश्यकता नहीं होगी क्योंकि केवल एक परिवर्तन आवश्यक होगा।

@FredyC यह एक अच्छी परियोजना है, लेकिन केवल tsc का उपयोग करते समय संकलक में ऐसा कुछ आसानी से इंजेक्ट करने के लिए हमें इस मुद्दे को हल करने की आवश्यकता होगी। उदाहरण के लिए, बेबेल-प्लगइन-मैक्रोज़ के साथ इसे अभी भी .babelrc में निर्दिष्ट करने की आवश्यकता है और टाइपस्क्रिप्ट में tsconfig.json में ऐसा कुछ निर्दिष्ट करना अच्छा होगा।

वास्तव में, क्या आप सुझाव दे रहे हैं कि टाइपस्क्रिप्ट में बेबेल-प्लगइन-मैक्रो-जैसे व्यवहार का निर्माण करना अच्छा होगा और कोई कॉन्फ़िगरेशन आवश्यक नहीं होगा? यह अच्छा हो सकता है, लेकिन व्यक्तिगत रूप से मैं एक विन्यास योग्य समाधान पसंद करूंगा जो tsconfig.json में कस्टम ट्रांसफार्मर निर्दिष्ट करने की अनुमति देता है और फिर टाइपस्क्रिप्ट एस्ट नोड्स का समर्थन करने वाले बैबेल-प्लगइन-मैक्रोज़ का एक संस्करण निर्दिष्ट किया जा सकता है।

@dsherret हाँ, मुझे उम्मीद नहीं है कि यह टाइपस्क्रिप्ट का ही हिस्सा होगा। हालांकि, मैं कल्पना कर सकता हूं कि एक बार ट्रांसफॉर्म तैयार हो जाने के बाद, tsc जैसा छोटा रैपर तैयार करना आसान हो सकता है जो मैक्रोज़ के लिए केवल उस ट्रांसफॉर्म को इंजेक्शन देगा और बाकी उपयोगकर्ता कोड से किया जा सकता है।

संपादित करें: वास्तव में, छोटा आवरण पहले से ही है, ऊपर उल्लिखित https://github.com/cevek/ttypescript के साथ इसे सार्वभौमिक मैक्रोज़ प्लगइन के साथ उपयोग करने का निर्देश देना आसान होगा और यह एक जीत है।

मुझे बस ऐसे लोगों को खोजने की जरूरत है जो टाइपस्क्रिप्ट ट्रांसफॉर्म से अच्छी तरह वाकिफ हों ताकि कुछ बुनियादी प्रोटोटाइप का पता लगाया जा सके। मैं चर्चा और बात कर सकता हूं, लेकिन इसे लागू करना मेरे वर्तमान कौशल से ऊपर है।

वे नहीं चाहते हैं कि आंतरिक में चीजों को तोड़ने में कठिनाई होने के डर से एक और एपीआई/सतह बनाए रखा जाए।

टाइपस्क्रिप्ट के साथ काम करने और इसके विकास को देखने के 3 साल बाद, मैं एक साधारण निष्कर्ष पर आया हूं। Microsoft के पास _code_ के अर्थ में ओपन-सोर्स टाइपस्क्रिप्ट है, लेकिन _process_ के अर्थ में नहीं। अधिकांश मामलों में, ओपन-सोर्स प्रोजेक्ट कमोबेश _निर्णय_ और _कोडिंग_ दोनों में समुदाय-संचालित होते हैं, और यह विकसित होने का स्वाभाविक तरीका होना चाहिए। क्या आपको node.js का IO.js कांटा याद है? समुदाय ने महसूस किया कि कंपनी के हित सामान्य ओपन सोर्स गवर्नेंस मॉडल के साथ इतने संरेखित नहीं थे, और उन्होंने बस फोर्क किया। मुझे आशा है कि टाइपस्क्रिप्ट के लिए ऐसा नहीं होगा, लेकिन Microsoft को इस संभावना को ध्यान में रखना चाहिए।
स्पष्ट होने के लिए, मैं देवों को दोष नहीं दे रहा हूं, वैसे भी, वे वास्तव में बहुत अच्छा काम करते हैं।
बस मेरा 2c, OT के लिए खेद है।

मैं सहमत हूं। यह स्पष्ट है कि समुदाय से मजबूत रुचि के बावजूद, देव कस्टम ट्रांसफॉर्मर/मैक्रोज़ के विचार को अस्वीकार कर रहे हैं, वास्तव में अस्वीकृति का कारण बताए बिना "लोग इसका दुरुपयोग करेंगे" की तर्ज पर कुछ को छोड़कर, जो समुदाय के प्रति अपमानजनक भी लगता है। जैसा कि इसका तात्पर्य है कि यह निम्न गुणवत्ता वाले देवों का समुदाय है।

यदि "हम इसे आसानी से नहीं करेंगे" के अलावा एक उचित औचित्य प्रदान किया जा सकता है, तो मैं एक अस्वीकृति स्वीकार करूंगा, लेकिन ऐसा लगता है कि समुदाय के सभी अनुरोधों के बावजूद किसी ने अभी तक इसे प्रदान करने का प्रयास नहीं किया है।

मुझे लगता है कि यह अनुचित आलोचना @pietrovismara है। मैं सहमत हूं कि यह एक अनिवार्य विशेषता है, लेकिन यह "माइक्रोसॉफ्ट" इस सुविधा को अवरुद्ध नहीं कर रहा है। टीम, जैसा कि मैं इसे समझता हूं, कह रही है कि इसका समर्थन करना आसान नहीं है और इसलिए उन्होंने अभी तक ऐसी सुविधा नहीं जोड़ी है।

फिर से, मुझे यह सुविधा किसी और की तरह चाहिए - लेकिन हमें तथ्यों का उपयोग करके इस मुद्दे पर चर्चा करने की आवश्यकता है। तथ्य यह है कि टीम अभी इसका समर्थन करने के लिए तैयार नहीं है। तो चलिए रुचि दिखाते रहें, लेकिन बातचीत को भी सही रास्ते पर रखें।

@mrmckeb अगर ऐसा है तो मैं इसे समझ सकता हूं। मैं उस समय इन मुद्दों में निहित टिप्पणियों की बड़ी धारा में इस तरह की घोषणा से चूक गया होगा। किसी को ठेस पहुँचाने का इरादा नहीं था, जैसा कि आपने कहा था, बातचीत को सही रास्ते पर रखने के लिए, बस मंटेनरों से स्पष्ट जवाब देने की कोशिश कर रहा था।

यह ठीक है, यह निराशाजनक है कि इसके लिए समर्थन मौजूद नहीं है - जैसा कि मैंने कहा, मैं इसे महसूस करता हूं, और हमें सीआरए में हर समय सीएसएस मॉड्यूल के लिए किसी तरह के समाधान के लिए कहा जाता है, अब हमारे पास टाइपस्क्रिप्ट समर्थन है। मुझे उम्मीद है कि यह जल्द ही आएगा, लेकिन मैं यह भी समझता हूं कि यह टीम के लिए जोखिम का एक बड़ा क्षेत्र खोलता है।

... अब भी इंतज़ार :(

हाँ, अभी भी इंतज़ार है..., लेकिन किस बात का इंतज़ार है, क्या कुछ किया गया है?

क्या अब ttypescript से कोई बेहतर उपाय है?
क्या टाइपस्क्रिप्ट डेवलपर अंततः प्लगइन्स का समर्थन करने की योजना बना रहे हैं?

आप अपना खुद का कंपाइलर बना सकते हैं ;-)

विषय पर कोई खबर? मुझे ऐसा लगता है कि समुदाय ने इस सुविधा का व्यापक रूप से उपयोग किया है ताकि वे बैठ सकें, प्रतिक्रिया एकत्र कर सकें, और अंत में कॉन्फ़िगरेशन फ़ाइल में ट्रांसफॉर्मर के लिए समर्थन जोड़ सकें। संदर्भ के रूप में उपयोग करने के लिए बहुत सारे कार्यान्वयन भी हैं।

2 साल से अधिक हो गए हैं (वाह!)*। क्या लोग ट्रांसफॉर्मर के लिए प्लगइन्स खोलने के पेशेवरों और विपक्षों पर पुनर्विचार करने के लिए खुले हैं?

मुझे ऐसा लगता है कि शुरुआती चिंताएँ जो उस समय पहले मौजूद थीं, जैसे कि एपीआई के बारे में दस्तावेज़ीकरण की कमी, और यूजरकोड <-> ट्रांसफॉर्मर <-> एपीआई के मेशिंग का समर्थन करना, अब उतना प्रासंगिक नहीं है। ओपन प्लगइन सपोर्ट ने बेबेल जैसे पैकेजों के लिए अद्भुत काम किया है: सहयोग के माध्यम से प्रगति। मैं व्यक्तिगत रूप से बेबेल को विशेष रूप से प्रमाणित कर सकता हूं, इसका व्यापक रूप से उपयोग कर रहा हूं।

ट्रांसफॉर्मर जैसे टाइपप्रति -है _would_ का एकीकरण आसान "बस काम करता है" अच्छा होगा। यह पैकेज विशेष रूप से मैं टाइपस्क्रिप्ट पर समग्र रूप से क्रांतिकारी प्रभाव को शांत करने के रूप में देखता हूं। सच्चे मजबूत अनुबंध! मैं

मुझे लगता है कि पेशेवरों और विपक्षों के बारे में बातचीत इस पर किसी भी तरह की आपत्ति या मतभेद को दूर करने में मदद करेगी। मुझे लगता है कि यह ज़ोंबी-मुद्दा तब तक चलता रहेगा जब तक ऐसा नहीं होता - ईमानदार होने के लिए।

* और इस बीच कोई व्यक्ति TS के बजाय ( ttypescript ) के लिए सुविधा बना रहा है। मैंने इसे सफलता के लिए इस्तेमाल किया है।

@DanielRosenwasser मैंने देखा कि 3.5 पुनरावृत्ति योजना पर "जांच टाइपस्क्रिप्ट प्लगइन एपीआई" था (और वह काम पहले ही शुरू हो चुका है)।
क्या वह बिंदु इस मुद्दे पर चर्चा की गई बातों को संभालता है? किसी मुद्दे के लिंक की कमी के कारण मुझे लगता है कि इसके बारे में अभी तक कुछ भी साझा करने के लिए यह बहुत अधिक WIP है?

मुझे लगता है कि बैबल पार्सर के लिए पूर्ण समर्थन जोड़ने पर काम किया जाना चाहिए, जिसमें टाइपस्क्रिप्ट स्थिर विश्लेषण का समर्थन करने के लिए बैबेल के लिए आवश्यक सुविधाओं को जोड़ना शामिल है (उदाहरण के लिए कई फाइल ट्रांसफॉर्म या ट्रांसफॉर्मेशन के दौरान कई फाइलों पर निर्भरता)। सिंटैक्स की नकल करने/बैबेल प्लगइन्स को टाइपस्क्रिप्ट समकक्षों में बदलने के बजाय।

यदि आपको निम्नलिखित निर्देश से कोई परेशानी है, तो मुझे बताएं, मुझे मदद करने में खुशी होगी

डिज़ाइन टीम की सरासर लापरवाही को देखते हुए, यहाँ एक समाधान है

हम tslint और इसकी कोड फिक्सिंग क्षमताओं का लाभ उठाने जा रहे हैं

निम्नलिखित उदाहरण में हम टाइप-टू-कोड ट्रांसफॉर्मेशन करने जा रहे हैं, इसके सबसे बुनियादी रूप में

हम कोड में स्थानों के मार्कर के रूप में डेकोरेटर का उपयोग करने जा रहे हैं जिन्हें फिर से लिखने की आवश्यकता है

हमारे मामले में, डेकोरेटर एक नकली फ़ंक्शन है जिसका एकमात्र लक्ष्य है

• परिवर्तन के स्थान को चिह्नित करने के लिए
• और उस प्रकार को पकड़ने के लिए जो जनरेटर के लिए सूचना का स्रोत बनने जा रहा है

प्रदर्शन उद्देश्यों के लिए, हम एक इंटरफ़ेस के नाम और प्रकार के गुणों को सादे स्ट्रिंग्स के रूप में, एक अंतर्निहित वर्ग में डंप करने जा रहे हैं

निम्नलिखित चरण केवल विंडोज़ उपयोगकर्ताओं के लिए हैं, यदि आप उनमें से एक नहीं हैं, तो भगवान आपकी मदद कर सकते हैं:

1. अपना वीएससीओडी शुरू करें
2. निम्नलिखित एक्सटेंशन स्थापित करें: https://github.com/Microsoft/vscode-typescript-tslint-plugin
3. अपना वीएससीओडी बंद करें
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 , अपनी अवधारणा साझा करने के लिए धन्यवाद - लेकिन कृपया सभ्य बनें।

डिज़ाइन टीम की सरासर लापरवाही को देखते हुए, यहाँ एक समाधान है

यह एक _feature_ को लागू नहीं करने के लिए टाइपस्क्रिप्ट को संबोधित करने का उपयुक्त तरीका नहीं है जिसे आप (और मेरे सहित कई अन्य) चाहते हैं। यह एक बड़ा दोष नहीं है, और "लापरवाही" का प्रतिबिंब नहीं है। कृपया सम्मान करें।

ओह, कृपया इसे व्यक्तिगत न लें, यही वह तरीका है जिससे मैं हमेशा अपनी शिकायतें शुरू करता हूं, मेरा व्यक्तित्व बहुत खट्टा है (चिकित्सीय स्थिति) और यह सबसे अच्छा है जिसे मैं खुद से बाहर निकाल सकता हूं, मुझे बहुत खेद है

आप लोग मुझे आश्चर्यचकित करना बंद नहीं करेंगे

• आप जो देख रहे हैं वह कोड का एक टुकड़ा है जो आज की एक बड़ी समस्या को आराम से हल करने में सक्षम लगता है (कोई चाल नहीं, कोई हैकिंग नहीं)
• यह वर्कअराउंड डिज़ाइन टीम के लिए एक जागृत कॉल है, और जैसा कि हमने पहले देखा था जब समुदाय गलत दिशा में एक मोड़ लेने वाला था, डिज़ाइन टीम तुरंत इसे संबोधित करने के लिए वहां मौजूद थी: #4212,
• इसलिए यदि वे परवाह करते हैं, तो वे इसे बहुत जल्दी कर सकते हैं जब तक कि बहुत देर न हो जाए, या यदि वे नहीं करते हैं, तो हम इस दिशा में खुदाई करने के लिए स्वतंत्र हैं और यह उनके लिए कोई समस्या नहीं होगी।
• इसलिए मेरी प्रतिक्रिया का लहजा कुछ अनुचित था, लेकिन आपके सभी उपयुक्त स्वर ने आपको 2 मार्च, 2017 (2 साल से अधिक) के बाद से कुछ भी नहीं दिया है, और हाँ, आप एक और 2 साल इंतजार कर सकते हैं

@zpdDG4gta8XKpMCd वास्तविक कार्यान्वयन में आपने क्या योगदान दिया है? टाइपस्क्रिप्ट खुला स्रोत है; मुझे इसमें कोई संदेह नहीं है कि यदि आपने एक (आंशिक रूप से भी) एक पुल अनुरोध बनाया है तो वे गंभीरता से विचार करेंगे।

एक चिकित्सा स्थिति पर अपनी अशिष्टता को दोष देना अस्वीकार्य है; वे ऐसे शब्द हैं जिन्हें आपने टाइप किया है और स्वेच्छा से "टिप्पणी" पर क्लिक करने के लिए चुना है। कोई भी चिकित्सीय स्थिति आपको ऐसा करने के लिए बाध्य नहीं करती है। बोलो, हो सकता है, टाइप न करें। आपको इसे हटाने के लिए अपनी टिप्पणी को संपादित करने का भी मौका मिला है, फिर भी आपने ऐसा नहीं किया है।

यदि आपको कस्टम ट्रांसफॉर्मर _now_ की आवश्यकता है, तो आप बैबेल का उपयोग कर सकते हैं। यह लगभग सभी टाइपस्क्रिप्ट से टाइप एनोटेशन को हटा सकता है, जबकि सिंटैक्स ट्रांसफ़ॉर्मेशन को आप जितनी आसानी से कर सकते हैं। एक बोनस के रूप में, यह तेज़ भी है।

मेरा सुझाव है कि आप Microsoft के भंडार से स्थायी रूप से निकाले जाने से पहले टिप्पणी करना बंद कर दें। मुझे पता है कि अगर यह मेरा रेपो होता, तो आप अपने आखिरी स्ट्रॉ पर होते।

ठीक है, तुमने मुझे बाहर निकाल दिया, फिर क्या
क्या मैं कभी वापस आ सकता हूँ? क्या मैं एक नया खाता बना सकता हूँ?
क्या आपको लगता है कि मुझे इस खाते की बहुत अधिक परवाह है?

वैसे भी, हाँ, मैंने पुल अनुरोधों की कोशिश की, दुर्भाग्य से यह निम्नलिखित कारणों से संभव नहीं है:

1. समस्याओं की एक निश्चित श्रेणी है जिसे हल करने के लिए आपका स्वागत है, जो कि मामूली और कम रुचि वाली हैं, इस तरह की कुछ भी गंभीर - और आप नहीं हैं

2. चूँकि आप इसे अपने आप हल नहीं कर सकते, इस तरह की एक समस्या (यहां तक ​​कि 224 अंगूठे ऊपर होने पर भी) वर्षों तक प्रतीक्षा कर सकती है यदि कभी भी विचार किया जाए

3. सौभाग्य से आज आपके पास जो भी साधन है उसका उपयोग करके आप कुछ कर सकते हैं और एक फर्क करना शुरू कर सकते हैं जिसे देखा जा सकता है, इसलिए सुझाव (मुझे कुछ भी न करने के लिए दोष न दें)

@ zpdDG4gta8XKpMCd जितना आप जानते हैं कि मैं वर्षों से निंदक का प्रशंसक रहा हूं, मुझे यहां दूसरों से सहमत होना होगा - हमें बातचीत को सभ्य और सम्मानजनक रखने की आवश्यकता है। यह हमेशा एक अच्छा अनुस्मारक है कि इस मुद्दे को ट्रैक करने वाला प्रत्येक व्यक्ति परियोजना को बेहतर बनाना चाहता है ।

@Janpot हाँ, यह बहुत अधिक WIP है, हालाँकि जब @rbuckton वापस आता है, तो वह स्थिति पर कुछ और विवरण देने में सक्षम हो सकता है।

जैसा कि हम प्लगइन बिंदुओं की जांच करते हैं (जैसा कि मैंने 3.5 पुनरावृत्ति योजना में बताया था), मुझे लगता है कि कस्टम ट्रांसफार्मर के लिए आसान हुक को उजागर करना एक प्रमुख परिदृश्य है जिस पर हम विचार करना चाहते हैं। इसका कारण यह नहीं है कि हम इसे एकमुश्त ही करेंगे क्योंकि हमारे पास व्यापक कार्य हो सकता है जो इसे समाहित करता है। दूसरे शब्दों में, हो सकता है कि केवल पूर्व और बाद के ट्रांसफार्मर की तुलना में कुछ व्यापक हो।

@DanielRosenwasser इसमें इतना निंदक नहीं है, मैंने केवल 2 शब्द कहे और फिर मैंने कहा कि मुझे इसके लिए गहरा खेद है

वैसे भी, मुद्दा यह है कि मुझे लगता है कि हम सभी सहमत हैं कि चीजें कैसे चलती हैं, इस पर स्वस्थ निराशा का एक अच्छा हिस्सा है, और हम इसे आप पर दोष नहीं देते हैं, हम समझते हैं कि इस परियोजना को क्या प्रेरित करता है

लेकिन अगर हम इसे अपने दृष्टिकोण से देखते हैं तो इसके लिए किसी को दोष देना होगा, क्योंकि इस तरह के मुद्दों को वर्षों तक बैठने देना सिर्फ अंगूठा इकट्ठा करना है, जो अधिक उत्पादक होने से रोकता है

मुझे यकीन है कि इसे बंद करने और पहले कुछ अन्य चीजों पर ध्यान केंद्रित करने के कारण हैं, इसलिए मुझे लगता है कि यह बेहतर होगा यदि आप अपने दर्शकों को बताएं कि कुछ अत्यधिक वांछित सुविधाओं को क्यों पूरा नहीं किया जा सकता है, इससे निराशा की डिग्री कम हो सकती है, कहें:

• हम ए, बीसी की वजह से इस सुविधा को लागू नहीं कर सकते हैं और उन्हें पहले डी, ई और एफ की जरूरत है

इसलिए मुझे लगता है कि मैं इस बातचीत का जिक्र कर रहा हूं: https://github.com/Microsoft/TypeScript/issues/30696#issuecomment -478799258

थम्स अप होने से पतली हवा से नए संसाधन नहीं बनते हैं, जटिल और कठिन निर्णय सरल और आसान होते हैं, मौजूदा व्यावसायिक प्राथमिकताओं को बदलते हैं, इन-फ़्लाइट प्रोजेक्ट्स को रोकते हैं, अन्य काम को प्राथमिकता देते हैं, अति-महत्वाकांक्षी प्रस्तावों को अच्छी तरह से दायरे में लाते हैं, या व्यापक और स्थायी प्रभावों के साथ एक सुझाव को केंद्रित और बनाए रखने योग्य बनाने के लिए बदलें।

मुझे इस तरह के अत्यंत जटिल और उच्च रखरखाव वाले काम से पहले अच्छी तरह से समझा जाने वाला अच्छा और सरल काम करने के लिए (या पीआर के लिए अनुमति देना , जिसके बारे में आप #30696 में शिकायत कर रहे थे) करने के लिए मुझे कोई खेद नहीं है। यह अनुमान लगाना कठिन नहीं होना चाहिए कि हम किसी को अंदर आने और एक टपका हुआ नल ठीक करने के लिए क्यों तैयार हैं, जबकि तहखाने को फिर से तैयार करने और घर के ऊपर एक और कहानी जोड़ने की योजना पर अभी भी काम किया जा रहा है।

@zpdDG4gta8XKpMCd आपको किसी को दोष क्यों देना चाहिए? आप पहली बार में खुद को दोष क्यों नहीं देते कि आपने इस समस्या को ठीक करने के लिए पीआर नहीं बनाया है? या कम से कम कुछ रचनात्मक लिखते हैं कि इसे कार्यान्वयन के दृष्टिकोण से कैसे देखा जाए?

अरे यार, उस पारदर्शी लेखन के बाद भी आपने अभी-अभी लिंक किया है कि आपने केवल 2 सप्ताह के बाद भालू को फिर से प्रहार करने का फैसला किया है? उस स्थिति में होने की कल्पना करने की कोशिश करें जिसमें हाथ में 1500+ कार्य हों और आपको उनमें से कुछ को चुनना होगा। हमारी टीम में, हम लगभग 100 कार्यों को आगे बढ़ा रहे हैं और काफी संघर्ष कर रहे हैं। कल्पना नहीं कर सकता कि यह 15 गुना अधिक होगा

भगवान के लिए @FredyC , यह कहने से पहले कि मैं कुछ नहीं कर रहा हूं, मेरे कामकाज को देखें

हाँ, मैं औपचारिक पुल अनुरोध नहीं कर रहा हूँ क्योंकि:

1. मैं एक अच्छा बनाने के स्तर तक नहीं हूं

2. साधारण लोगों के लिए, अनुमोदन की एक लंबी लाइन है, और 2 साल पहले बनाए गए पुल अनुरोध को वर्तमान कोडबेस के साथ अद्यतित रखने के लिए जबरदस्त काम करना पड़ता है, मेरे पास इतना समय नहीं है

3. कुछ समस्याओं पर विचार भी नहीं किया जाएगा, भव्य डिजाइन के विचारों को देखते हुए जिनके बारे में एंडर्स हेजलबर्ग जैसे कुछ ही लोग जानते हैं

आप हताशा वाले हिस्से को दूर नहीं कर सकते, और मैं यहाँ अकेला नहीं हूँ

हम जानते हैं कि खेल में ये कारक हैं:

• भाषा का भव्य डिजाइन
• 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 के साथ उपयोग किया जा सके। क्या आप संपादक में कस्टम कोड परिवर्तन/सुधार करना चाहते हैं?

मैंने उनका बिल्कुल भी उपयोग नहीं किया है, लेकिन मुझे लगता है कि आप जिस बारे में बात कर रहे हैं वह भाषा सेवा प्लगइन के साथ पहले से ही संभव हो सकता है (मुझे लगता है कि भाषा सेवा पर getCodeFixesAtPosition को ओवरराइड करके और अपनी कोड कार्रवाइयां डालने से ... हालांकि निश्चित नहीं है) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

या शायद मैं गलत समझ रहा हूँ?

सही। ठीक यही मैं सोचता था

मैंने सोचा था कि tsconfig.json के माध्यम से मेरे कस्टम ट्रांसफॉर्म को निर्दिष्ट करने का एक तरीका एक सपना सच होगा

लेकिन तब मुझे एहसास हुआ कि मुझे अपना वर्कअराउंड और भी अच्छा लगता है

यहाँ मेरी सोच की रेखा है:

• मुझे एक प्लग करने योग्य विन्यास योग्य कोड जनरेटर की आवश्यकता है
• टाइपस्क्रिप्ट में ऐसा कुछ भी आसान नहीं है
• दूसरी ओर मुझे पता है कि tslint (हालांकि 2019 के अंत तक मूल्यह्रास किया जा रहा है) टाइपस्क्रिप्ट के लिए एक अच्छा प्लगइन प्लेटफॉर्म है जिसमें आपके कोड को बड़ी स्वतंत्रता के साथ प्लगइन और कॉन्फ़िगर करने का एक तरीका है
• पता चला कि इसमें वह सब है जो मुझे चाहिए:
  
  
  
  • प्लग करने योग्य और विन्यास योग्य
  
  
  • सभी आवश्यक UI . के साथ
  
  
  • मुझे टाइपप्रति के लिए एक एपीआई देता है
  
  
  • कुछ अतिरिक्त है
  
  

यह सब दिया गया है कि मैं खुद को कुछ ऐसा लिखते हुए नहीं देख सकता जो टाइपस्क्रिप्ट भाषा सेवा का उपयोग करता है, क्योंकि:

• मेरा लैपटॉप केवल उतनी ही टाइपस्क्रिप्ट भाषा सेवाओं को धारण कर सकता है, और उनमें से कुछ पहले से ही हैं:
  
  
  
  • बनामकोड में से एक
  
  
  • tslint . में से एक
  
  

और मैं उसके ऊपर एक और जोड़ना नहीं चाहता

काश मेरे पास अपने कोड ट्रांसफॉर्मर में प्लगिंग का एक बेहतर तरीका होता, लेकिन हमारे पास वह है जो हमारे पास है

और इस तरह हम मैक्रोज़ करते हैं: #4892

• मेरा लैपटॉप केवल उतनी ही टाइपस्क्रिप्ट भाषा सेवाओं को धारण कर सकता है, और उनमें से कुछ पहले से ही हैं:

  • एक के बाद एक vscode
  • एक द्वारा tslint

@zpdDG4gta8XKpMCd मेरा मानना ​​है कि सब कुछ एक ही भाषा सेवा का उपयोग करना चाहिए। तो आपके पास एक ही भाषा सेवा होगी और फिर आपके प्लगइन के साथ tslint प्लगइन प्रॉक्सी करेगा।

बीटीडब्ल्यू, आप यहां जो करने की कोशिश कर रहे हैं वह निश्चित रूप से एक सादे भाषा सेवा प्लगइन के साथ संभव होना चाहिए क्योंकि यहां यही किया गया है।

वैसे भी, आइए यहां विषय पर और केवल कस्टम ट्रांसफॉर्मर के बारे में संपादक कोड परिवर्तन/भाषा सेवा सामग्री के बजाय tsc के साथ निर्माण के हिस्से के रूप में बातचीत को रखने का प्रयास करें। अधिकांश लोग एक संपूर्ण परियोजना में परिवर्तन करने के लिए एक समाधान की तलाश कर रहे हैं और संपादक के भीतर ऐसा करना एक व्यवहार्य समाधान नहीं है (विशेषकर जब से उस बिंदु पर एक परिवर्तन करना उनका उपयोग करने के उद्देश्य को हरा देता है)। आदर्श रूप से जो यहां लागू किया जाना चाहिए उसका संपादक/tsserver या भाषा सेवा से कोई लेना-देना नहीं होना चाहिए।

बहुमूल्य इनपुट के लिए धन्यवाद, मैं इस पर विचार करूंगा

tsc के साथ निर्माण के हिस्से के रूप में केवल कस्टम ट्रांसफार्मर के बारे में बातचीत रखने पर मैं आपसे असहमत हूं, क्योंकि

• लिखित रूप में मूल अनुरोध विशिष्ट नहीं है कि किस रूप में डिलीवर किया जाना है, यह केवल यह बताता है कि उन्हें करने की आवश्यकता नहीं होनी चाहिए
  > केवल एक ट्रांसफॉर्मर जोड़ने के लिए संपूर्ण tsc कमांड लाइन को डुप्लिकेट करें
• 2 वर्षों में इस चर्चा ने बहुत से लोगों का ध्यान आकर्षित किया है, जो इस बात की परवाह नहीं करते हैं कि ट्रांसफार्मर कैसे लागू किए जाते हैं, बशर्ते कोई समाधान हो, यह काम करता हो और इसका उपयोग करना आसान हो
• इसके अलावा, tslint टीम ने प्लगइन्स के लिए बुनियादी ढांचे का निर्माण करने के लिए एक अच्छा काम किया, इसका उपयोग नहीं करना प्रयास की बर्बादी है, बशर्ते यह टाइपस्क्रिप्ट के बाहर एकमात्र आधिकारिक रूप से मान्यता प्राप्त प्लेटफॉर्म है जो टाइपस्क्रिप्ट से संबंधित है
• इसके अलावा, हम सभी इस बात से सहमत हैं कि भले ही ट्रांसफॉर्मर कभी भी भाषा के लिए अपना रास्ता खोज लें, यह जल्द ही कभी नहीं होने वाला है, लेकिन यहां (मेरे सहित) लोगों को कल की तरह उनकी जरूरत थी
• अंत में, चूंकि इतने बेहतर विकल्प नहीं हैं, हम कम से कम हमारे पास जो कुछ भी है उस पर विचार क्यों नहीं करेंगे?

मेरे सुझाव को स्पष्ट रूप से वर्कअराउंड के रूप में लेबल किया गया है (जबकि डिज़ाइन टीम उचित समाधान पर कठिन सोचने के लिए अपना समय ले रही है), तो क्यों नहीं?

यदि आप जोर देते हैं कि हमें इसे कहीं और करना चाहिए, तो कृपया बोलें

लेकिन a करने की आपकी चिंता को दूर करने के लिए

एक पूरी परियोजना में बदलना

tslint अपने --fix तर्क के साथ cli . के लिए ठीक वैसा ही करता है

@zpdDG4gta8XKpMCd --fix जगह पर टाइपस्क्रिप्ट कोड अपडेट करेगा। यह समस्या उत्सर्जन के दौरान परिवर्तन करने के बारे में है (इसलिए परिवर्तन केवल अंतिम जावास्क्रिप्ट फ़ाइलों में समाप्त होते हैं)। संदर्भित मुद्दे का पीआर (#13940) देखें:

चूंकि #13764 आ चुका है, इसलिए कस्टम ट्रांसफॉर्मर लिखना आसान है। हालांकि, अगर मैं एपीआई को सही ढंग से समझता हूं, तो केवल एक ट्रांसफॉर्मर जोड़ने के लिए पूरी टीएससी कमांड लाइन को डुप्लिकेट करने की आवश्यकता है। यह असंगतता की ओर ले जाता है, क्योंकि टाइपस्क्रिप्ट के आधार पर, एप्लिकेशन tsc कमांड लाइन टूल के समान सुविधाओं का समर्थन नहीं करते हैं।

दूसरे शब्दों में, वह मुद्दा CustomTransformers लाया (उस लिंक पर क्लिक करें और देखें कि यह एपीआई में कहां उपयोग किया गया है), लेकिन उनका उपयोग करने के लिए tsc को किसी भी तरह डुप्लिकेट या लपेटने की जरूरत है, जो कि क्या है टाइपस्क्रिप्ट करता है। दूसरा पैराग्राफ तब इस बारे में बात करता है कि यह कैसे अच्छा होगा क्योंकि यह मौजूदा बिल्ड टूल्स में अच्छी तरह से एकीकृत होगा (चूंकि कस्टम ट्रांसफॉर्मर का उपयोग करने के लिए इसे अलग-अलग तरीकों से करने वाले विभिन्न बिल्ड टूल्स के बजाय टीएससी द्वारा नियंत्रित किया जाएगा)।

मुझे लगता है कि कोड फिक्स के साथ आपकी चिंताओं के साथ एक नया मुद्दा खोलना अधिक उत्पादक होगा या टाइपस्क्रिप्ट कोड के भीतर टाइपस्क्रिप्ट कोड उत्पन्न करने का एक आसान तरीका चाहते हैं। मुझे यकीन नहीं है कि वास्तव में वे चिंताएं क्या हैं क्योंकि मुझे लगता है कि इसमें से बहुत कुछ आज पहले से ही संभव है, लेकिन आप जो चर्चा कर रहे हैं वह कोड फिक्स/कार्रवाइयां कैसे करें, जो मेरे लिए एक असंबंधित विषय की तरह लगता है।

मुझे लगता है कि इस सूत्र में उत्तर देने के लिए मुख्य प्रश्न हैं जो डैनियल ने चर्चा की- "शायद पूर्व और पोस्ट-ट्रांसफॉर्मर की तुलना में कुछ व्यापक है" - और निर्माण के इस हिस्से को बनाने का समाधान कैसा दिखेगा।

तुम अस्पष्ट हो

मैं एक ऐसा व्यक्ति हूं जो साधारण चीजों को समझता है और उनकी सराहना करता है

मेरी समस्या यह है कि मैं कुछ 3500+ फाइल प्रोजेक्ट से निपट रहा हूं, जिनमें से 15% को हाथों से लिखने और बनाए रखने की आवश्यकता नहीं है और इसके ऊपर लगभग 5% समान सामान आने के लिए हैं

उसी समय मुझे पता है कि एक एपीआई है जो इसे मेरे लिए कर सकती है, लेकिन यह इतना आधा-बेक्ड है कि मैं इसे पूरी तरह से बेक करने के लिए अपने समय को कभी भी उचित नहीं ठहरा सकता

इसलिए जब मैं यहां आया तो मैंने सोचा कि इसके बारे में बात करने के लिए यह सही जगह है, और पता चला कि एक त्वरित और सरल समाधान हो सकता है

बदकिस्मती है कि कुछ लोग जो यहां आए हैं, वे कुछ बेहतर मुद्दों पर चर्चा करने वाले हैं

ठीक है, बकाया!

और नहीं, मैं सिर्फ लोगों को एक बार फिर यह दिखाने के लिए एक नया मुद्दा नहीं खोलने जा रहा हूं कि कैसे tslint एक बड़ी समस्या को हल कर सकता है, मैंने अपना काम किया, मैं कर चुका हूं

बॉक्स के बाहर विन्यास योग्य परिवर्तन करना अच्छा होगा। मैं इन-कोड स्ट्रिंग l10n और i18n की समस्या से निपटने का प्रयास कर रहा हूं। मैं निष्कर्षण के लिए एक कस्टम नियम के साथ tslint जैसे टूल का लाभ उठा सकता हूं, लेकिन कोड को बदलने के मेरे विकल्प सीमित हैं, जब तक कि मैं ttypescript जैसी किसी चीज़ का उपयोग नहीं करता, लेकिन यह समस्याग्रस्त है क्योंकि मैं जिस ऐप का उपयोग कर रहा हूं जिस पर काम करना एक अन-इजेक्टेड एंगुलर ऐप है। यह सिर्फ मुझे बिल्ड टूल्स की परत दर परत जोड़ने के लिए मजबूर करता है। विकास की गति के साथ पूरा ढेर वास्तव में अनिश्चित हो जाता है।

हम वर्तमान में एक ढांचा विकसित कर रहे हैं और हम वर्तमान में ttypescript का उपयोग कर रहे हैं ताकि रनटाइम पर टाइप-लेवल जानकारी तक पहुंच सकें, आधिकारिक कंपाइलर में plugins विकल्प अंततः अच्छा होगा

मैं अभी छुट्टी पर हूं लेकिन अगले सप्ताह जब मैं वापस आऊंगा तो देखूंगा

रविवार, 21 जुलाई, 2019 को शाम 5:54 बजे जियोर्जियो बोआ नोटिफिकेशन @github.com
लिखा था:

@longlho https://github.com/longlho आपने बहुत बढ़िया एस्ट बनाया है
ट्रांसफार्मर, मुझे आपकी मदद चाहिए कृपया
मैं वास्तव में कोणीय संकलन से पहले डेकोरेटर मेटाडेटा को संशोधित करना चाहूंगा।
मेरा लक्ष्य इस नोड को संशोधित करना है
घटक ({चयनकर्ता: 'मानक' ...}) घटक में ({चयनकर्ता: 'कस्टम'
...})
मैंने इसे परीक्षण के लिए एक जीथब रेपो बनाया है
https://github.com/gioboa/ng-ts-transformer । मुझे लगता है कि यह संभव है लेकिन
दस्तावेज़ीकरण के बिना मुझे कुछ मदद चाहिए। 🙏 धन्यवाद।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW86DN#ZGODWSHJ657DN#
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
.

मैंने प्रॉक्सी के बिना इंटरफेस से वास्तविक नकली बनाने के लिए पुस्तकालय बनाने में योगदान दिया है। मैं अभी के लिए ttypescript का उपयोग करने की अनुशंसा कर रहा हूं लेकिन टाइपस्क्रिप्ट के साथ एक एकीकृत तरीका होना अच्छा होगा

मैं वास्तव में इस सुविधा को होते देखना पसंद करूंगा। मुझे पूरा यकीन है कि टाइपस्क्रिप्ट और कुछ सबसे महान नवाचारों के बीच यही एकमात्र चीज है जो इससे हो सकती है।

फ्रंटएंड डेवलपमेंट में टाइपस्क्रिप्ट का बहुत बड़ा योगदान है, लेकिन यह आगे के इनोवेशन पर भी ब्रेक लगाता है…
शब्दार्थ को मत तोड़ो। कोई प्लगइन एटीएम शब्दार्थ को नहीं तोड़ सकता; और प्लगइन्स की बिल्कुल भी अनुमति नहीं है :man_shrugging: क्यों?
वास्तव में अच्छे प्लगइन्स हैं, लेकिन। प्रत्येक प्लगइन को (कुंजी) शब्द टोकननाइजेशन और एएसटी इंस्टेशन) का सम्मान करना चाहिए ..., अंदर कुछ करने का वास्तव में कठिन तरीका।
यह इतना कठिन नहीं है। यह आसान नहीं है, लेकिन बेबेल परियोजना से पता चलता है कि यह संभव है।
वास्तव में बैबेल के लिए नए शब्दार्थ या वाक्य-विन्यास वाक्यांशों को पेश करना लगभग तुच्छ है।

मैं शब्दार्थ की अनुमति देने के लिए टाइपप्रति से अपेक्षा नहीं करता। (मैं भी निश्चित रूप से वाक्यविन्यास परिवर्तन की उम्मीद नहीं कर रहा हूँ!)
मैं जो चाहता हूं वह कंपाइलर से कुछ मामलों में शिफ्ट है, जैसे (केवल प्रकार हो सकता है) प्रीवल।
जैसे कि अगर मेरे पास एक समारोह है, जैसे route या message या कुछ और, संकलक प्रचलित हो सकता है और (ओह, कृपया, चरण एक पर) शुद्धता की जांच करें।

अगर आप मेरे पिछले पैराग्राफ को अजीब पढ़ रहे हैं। tsx और सभी प्रतिक्रिया अच्छाई क्या है?

कोई प्रतिक्रिया नहीं, कोई प्रवाह नहीं, कोई टाइपस्क्रिप्ट बिल्कुल नहीं, लगभग नज़र में नहीं।

कृपया। मैं यह सब ध्यान से देख-पढ़कर अच्छी तरह समझ रहा हूँ; लेकिन जैसा कि हम IE5.5+ से सीखते हैं; अवरुद्ध करना कोई रास्ता नहीं है।

अगर कुछ सुधार की जरूरत है, तो यह अभी भी लेआउट इंजन है। डी. नुथ गुनी थे जिन्होंने 50 साल पहले सभी लापता भागों को डिजाइन किया था। आज हमारे पास यह क्यों नहीं है ?? :-)
कृपया, लोगों को जेएस बुराई में सीएसएस को रोकने के लिए कहें।

कृपया। शब्दार्थ बुद्धि के लिए खुला TS ; स्थिर स्ट्रिंग इनपुट के साथ फ़ंक्शन की तरह, बाकी के लिए प्रकार संकेत प्रदान करना; वास्तविक कॉन्स्ट इनपुट स्ट्रिंग का विश्लेषण करें ...
एक छोटा सा उदाहरण:

• ग्राफकॉल कॉल रिटर्न शेप
• इंटेल इनपुट आकार
• …बहुत अधिक_
  कृपया। कोई शब्दार्थ परिवर्तन की आवश्यकता नहीं है। सब कुछ इच्छानुसार काम करेगा। बिल्ड समय पर कुछ और चेक किया जा सकता है। बस आज के लिए इतना ही! :खरगोश:

टक्कर

मैं @babel/preset-env और @babel/runtime जैसे लक्ष्य परिवेशों के लिए ऑप्टिमाइज़ेशन core-js आयात - स्वचालित पॉलीफ़िलिंग के लिए TS ट्रांसफ़ॉर्म लिखने का प्रयोग कर रहा हूँ, लेकिन बिना babel के। यह टीएस डेवलपर्स के एक बड़े हिस्से की गंभीरता से मदद कर सकता है। लेकिन समर्थन के बिना ttypescript जैसे अतिरिक्त टूल के बिना बॉक्स से कस्टम रूपांतरण, उन परिवर्तनों का उपयोग करने की संभावना गंभीरता से सीमित होगी, इसलिए मुझे यकीन नहीं है कि यह समझ में आता है।

मैं इस तरह के एक विचार के साथ प्रयोग कर रहा हूं - https://github.com/webschik/typescript-polyfills-generator।
मुझे लगता है कि ट्रांसफॉर्मर्स एपीआई विकास श्रृंखला से babel छोड़ने की संभावना खोलेगा। मुझे लगता है कि बहुत से डेवलपर उन दोनों का उपयोग नहीं करना चाहते हैं, लेकिन उन्हें अभी भी @babel/preset-env जैसे प्लगइन्स की आवश्यकता है।

इस सीमा के कारण हमने वर्तमान में अपनी स्वयं की कस्टम कंपाइलर स्क्रिप्ट (टाइपस्क्रिप्ट कंपाइलर एपीआई का उपयोग करके) को रोल किया है। हमने संक्षेप में ttypescript को देखा, लेकिन वैनिला टाइपस्क्रिप्ट कंपाइलर से टाइपस्क्रिप्ट कंपाइलर के विस्तार में जाने की भूख बस नहीं है।

यह शानदार होगा यदि कस्टम ट्रांसफार्मर tsconfig.json में समर्थित थे। एक स्क्रिप्ट लिखना बोझिल है जो बस tsconfig को पार्स करता है, ट्रांसफॉर्मर घोषित करता है, फिर कंपाइलर चलाता है; या, इससे भी बदतर, वास्तव में संकलक की मूलभूत सुविधाओं को फिर से लागू करने का प्रयास करने और प्रयास करने के लिए, जैसे फाइलें देखना, एक कस्टम स्क्रिप्ट में।

अन्य लोग इस भावना को प्रतिध्वनित कर रहे हैं, लेकिन कस्टम ट्रांसफॉर्मर को कंपाइलर में एकीकृत करने में आसानी के लिए टाइपस्क्रिप्ट डेवलपमेंट टीम का एक महत्वपूर्ण भार होगा और समुदाय से इस भाषा के साथ नवाचार और अतिरिक्त आगे की गति की अनुमति देगा।

एक बहुत ही सफल प्लगइन पारिस्थितिकी तंत्र का एक उदाहरण सर्वर रहित फ्रेमवर्क का प्लगइन समुदाय है। विकास दल फीचर विकास की मांग को पूरा नहीं कर सकता है, और प्लगइन्स नई (संभवतः प्रयोगात्मक) सुविधाओं के एकीकरण के लिए अनुमति देने के लिए पीआर खोलने या मुख्य उत्पाद को सुविधाओं के साथ पानी के नीचे पानी की आवश्यकता के बिना अनुमति देता है जो हो सकता है या हो सकता है व्यापक उपयोगकर्ता आधार को मूल्य प्रदान न करें।

मैं एक पुस्तकालय का निर्माण कर रहा हूं और मेरे पास इसमें सज्जाकार हैं जो मेरे लिए बहुत अच्छा काम करते हैं और जिस पर मैं निर्भर हूं। मुझे कुछ समय पहले एहसास हुआ कि सज्जाकार मेरी लाइब्रेरी को पेड़-काटने योग्य नहीं बनाते हैं। इसे देखने के बाद मैं इस निष्कर्ष पर पहुंचा कि ट्रांसफॉर्मर संकलन पर उन डेकोरेटर्स को ट्री-शेकेबल कोड में बदलने में मेरी मदद कर सकते हैं। यह दुर्भाग्यपूर्ण है कि मैं उन्हें अपनी पाइपलाइन में परिभाषित नहीं कर सकता। मुझे आशा है कि आप इस मुद्दे पर जल्द ही पहुंचेंगे, बस अपने 2 सेंट को एक उपयोग के मामले में छोड़ना चाहता हूं जहां यह बहुत मददगार होगा।

रैपर प्रोग्राम और जटिल निर्देशों के बिना टाइपस्क्रिप्ट समर्थन कस्टम ट्रांसफॉर्मर बनाने के हित में, मैंने ts-patch ( npm github ) नामक एक टूल लिखा है।

बस ts-पैच (विश्व स्तर पर या स्थानीय रूप से) स्थापित करें और टाइपस्क्रिप्ट पैच करने के लिए ts-patch install चलाएं। आप टाइपस्क्रिप्ट इंस्टॉलेशन डायरेक्टरी को भी निर्दिष्ट कर सकते हैं और/या दृढ़ता को सक्षम कर सकते हैं, जो टीएस को अपडेट या रीइंस्टॉल करने पर पैच को बनाए रखता है। (विवरण: ts-patch /? )

पैच लॉजिक ज्यादातर ttypescript पर आधारित होता है। (सेवेक के महान कार्य के लिए बहुत-बहुत धन्यवाद!) इसे इस तरह से लिखा गया है जहां इसे आसानी से npm पैकेज इंस्टाल प्रक्रिया में जोड़ा जा सकता है। इसे अनपैच करना भी आसान है।

स्पष्ट होने के लिए, यह सीधे टाइपप्रति में प्रासंगिक फाइलों को पैच करता है और एक रैपर नहीं है। डिपेंडेंसी इंस्टॉलेशन के बाद बस पैच चलाएं, और टाइपस्क्रिप्ट ट्रांसफॉर्मर तैयार हो जाएगा।

उम्मीद है कि यह कुछ लोगों की मदद करता है!

रैपर प्रोग्राम और जटिल निर्देशों के बिना टाइपस्क्रिप्ट समर्थन कस्टम ट्रांसफॉर्मर बनाने के हित में, मैंने ts-patch ( npm github ) नामक एक टूल लिखा है।

बस ts-पैच (विश्व स्तर पर या स्थानीय रूप से) स्थापित करें और टाइपस्क्रिप्ट पैच करने के लिए ts-patch install चलाएं। आप टाइपस्क्रिप्ट इंस्टॉलेशन डायरेक्टरी को भी निर्दिष्ट कर सकते हैं और/या दृढ़ता को सक्षम कर सकते हैं, जो टीएस को अपडेट या रीइंस्टॉल करने पर पैच को बनाए रखता है। (विवरण: ts-patch /? )

पैच लॉजिक ज्यादातर ttypescript पर आधारित होता है। (सेवेक के महान कार्य के लिए बहुत-बहुत धन्यवाद!) इसे इस तरह से लिखा गया है जहां इसे आसानी से npm पैकेज इंस्टाल प्रक्रिया में जोड़ा जा सकता है। इसे अनपैच करना भी आसान है।

स्पष्ट होने के लिए, यह सीधे टाइपप्रति में प्रासंगिक फाइलों को पैच करता है और एक रैपर नहीं है। डिपेंडेंसी इंस्टॉलेशन के बाद बस पैच चलाएं, और टाइपस्क्रिप्ट ट्रांसफॉर्मर तैयार हो जाएगा।

उम्मीद है कि यह कुछ लोगों की मदद करता है!

क्या इसे उचित समर्थन जोड़ने/चर्चा करने के लिए पीआर के रूप में उठाया जा सकता है? :)

अरे। इसके लायक क्या है, फ़्यूज़-बॉक्स नामक एक बंडलर है जो कस्टम ट्रांसफार्मर को जोड़ना बहुत आसान बनाता है। इसका 4.0 संस्करण जल्द ही आ रहा है... इसलिए यह बीच में है। लेकिन कुल मिलाकर, मुझे वास्तव में बंडलर पसंद है। शायद यह आपकी भी मदद कर सके।

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

क्या इसे उचित समर्थन जोड़ने/चर्चा करने के लिए पीआर के रूप में उठाया जा सकता है? :)

TS टीम ने व्यक्त किया है कि वे इसे मूल विशेषता के रूप में प्रदान नहीं करना चाहते हैं। निर्णय के उनके कारण समझ में आते हैं!

अच्छी खबर यह है कि क्योंकि TS खुला स्रोत है और पहले से ही एक मॉड्यूलर फैशन में संकलित है, ts-पैच एक तरह से व्यवहार करता है जैसे कि अगर इसे बनाया गया होता। तो यह बग्गी रिवर्स इंजीनियर बाइटकोड पैच की तरह नहीं है।

यदि समर्थन द्वारा, आप इसे बनाए रखने के बारे में चिंतित हैं, तो मेरी योजना इसे चालू रखने और TS के सभी भावी संस्करणों के लिए काम करने की है! मेरा बहुत सारा वाणिज्यिक बुनियादी ढांचा पहले से ही इस पर निर्भर है।

एक साइड नोट के रूप में, मैं जल्द ही एक नया संस्करण जारी करूंगा जो एक ही पैकेज में विभिन्न प्रवेश बिंदुओं के साथ कई प्लगइन्स को पैकेज करने की अनुमति देता है और साथ ही इसे बेहतर बनाने और इसे उपयोग करने में आसान बनाने के लिए कुछ अन्य अनुकूलन की अनुमति देता है।

एक प्लगइन लिखने के बाद मैं सराहना कर सकता हूं कि टीएस टीम क्यों हिचकिचा रही है - वर्तमान ट्रांसफॉर्मर एक पोस्ट-कंपाइल चरण है। यदि आप कुछ भी जटिल करते हैं और नई सामग्री जोड़ना शुरू करते हैं जो मूल रूप से बाध्य नहीं थी, तो आप खराब समस्याओं में भाग लेते हैं। जैसा कि यह खड़ा है, ts-node --compiler ttypescript foo.ts पूरी तरह से ठीक काम करता है। मैं चाहता हूं कि ts टीम विभिन्न संकलन चरणों में ट्रांसफॉर्मर प्लगइन्स से निपटे ... या एक रिबाइंडिंग चरण की अनुमति दें।

वर्तमान ट्रांसफॉर्मर एक पोस्ट-कंपाइल चरण है। यदि आप कुछ भी जटिल करते हैं और नई सामग्री जोड़ना शुरू करते हैं जो मूल रूप से बाध्य नहीं थी, तो आप खराब समस्याओं में भाग लेते हैं।

ट्रांसफॉर्मर टीएससी संकलन से पहले या बाद में चल सकते हैं। ऐसा लगता है कि आप जिस बात का जिक्र कर रहे हैं वह यह है कि चेकर नोड्स को संशोधित करने के बाद अपडेट नहीं होता है। इसे वास्तव में दरकिनार किया जा सकता है, कार्यक्षमता को इसके लिए नहीं बनाया गया था। जब आप ts.transform() का आह्वान करते हैं, तो यह आपके साथ काम करने के लिए एक पूर्ण प्रोग्राम इंस्टेंस नहीं बनाता है, इसलिए यदि आप चेकर के साथ काम करना चाहते हैं, तो आपको एक बनाना होगा। कंपाइलरहोस्ट का उपयोग करके, आप एएसटी को बदलने के बाद इसे संशोधित फाइलों के साथ पुनः लोड कर सकते हैं।

मैं अभी तक इसमें बहुत दूर नहीं गया हूं, लेकिन ऐसा लगता है कि हर बार पूरे प्रोग्राम इंस्टेंस को पुनर्निर्माण करने से बचने के लिए 'घड़ी' कार्यक्षमता का उपयोग करना भी संभव हो सकता है। सीधे शब्दों में कहें, तो यह पता चलता है कि वास्तव में अधिक पूर्ण प्लगइन सिस्टम होना मुश्किल नहीं है, लेकिन ट्रांसफॉर्म में इसके प्रदान किए गए संदर्भ में समर्थन का अभाव है।

@nonara मैंने ttypescript और ts-loader` के साथ ट्रांसफॉर्म का उपयोग किया है, दोनों में पूर्ण प्रोग्राम एंट्री पॉइंट हैं। मेरी समस्या यह है कि यदि आप एक नया आयात विवरण जोड़ते हैं, तो उसके लापता "कुछ" और उन नए बयानों को अंतिम आउटपुट उत्सर्जन से हटा दिया जाता है। @weswigham कहते हैं क्योंकि ट्रांसफॉर्म एक बाध्यकारी कदम है । समाधान स्पष्ट रूप से फ़ाइल के लिए एक पूरी तरह से नया प्रोग्राम बनाना है - लेकिन जब आप टीएस-लोडर जैसी चीजों से निपट रहे हैं तो यह सिरदर्द की तरह लगता है (विशेष रूप से जब यह केवल ट्रांसफॉर्म मोड में होता है और पूरी तरह से वेबपैक/बंडलर फ़ाइल को छुपाता है- रिज़ॉल्वर। अंत में मैंने आयात छोड़ दिया और मुझे आवश्यक कोड को रेखांकित किया ।

@MeirionHughes आह, ठीक है। उस स्थिति में, हाँ, आपके पास प्रोग्राम इंस्टेंस है। ttypescript ट्रांसफॉर्मर को शामिल करने के लिए परिणामी program की एमिट विधि को पैच करने के लिए createProgram को हुक करके काम करता है।

• प्रक्रिया के दौरान ts.emitFiles ts.transformNodes $ पर कॉल करता है।
• ts.transformNodes को प्रोग्राम इंस्टेंस के साथ या बिना कॉल किया जा सकता है। सीधे ts.transform() को कॉल करना बिना किसी के कॉल करता है।

अगर मैं इसे सही ढंग से समझ रहा हूं, तो ऐसा लगता है कि आपकी समस्या भी इस तथ्य से जुड़ी हुई है कि प्रकार और प्रतीक पहले ही चल चुके हैं, और वे एएसटी परिवर्तन के बाद अपडेट नहीं होते हैं।

सभी को नमस्कार, मैं एक ट्रांसफॉर्मर हैंडबुक लिख रहा हूं ताकि ट्रांसफॉर्मर के बारे में सारी जानकारी एकत्र की जा सके और साथ ही इसे शुरू करना आसान बनाया जा सके।

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

यदि आप एक सेकंड के लिए अतिरिक्त कर सकते हैं तो उस पर कुछ निगाहें पसंद आएंगी

@madou मैंने टीएस ट्रांसफार्मर पर एक बंच पोस्ट भी लिखा 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 - लेकिन प्रथम श्रेणी प्लगइन समर्थन के बिना उन्हें एक परियोजना में शामिल करना एक जोखिम भरा तकनीकी निर्णय जैसा लगता है। प्लगइन्स को मूल रूप से सक्षम करने से समुदाय को संभावित भविष्य की टाइपस्क्रिप्ट सुविधाओं के साथ खेलने की अनुमति मिल जाएगी, इससे पहले कि उन्हें कोर लाइब्रेरी में शामिल करने की आवश्यकता हो।

मुझे लगता है कि टाइपस्क्रिप्ट टीम को अपने तर्क पर फिर से विचार करना चाहिए। प्लगइन इको-सिस्टम भाषा को आगे बढ़ाने, प्रयोगों को सक्षम (और प्रोत्साहित करने) का एक सिद्ध तरीका है (हास्केल को इसके प्राग्मास के साथ देखें)।

उन प्रयोगों में से कुछ जंगली और पागल होंगे, और कुछ अंततः स्थिर और सामान्य हो जाएंगे। उपयोगकर्ता स्थान में भाषा सुविधाओं को लागू करने की क्षमता प्रदान करना हमेशा अच्छा होता है।

सामान्य तौर पर, टाइपस्क्रिप्ट टीम की स्थिति अनावश्यक कठोर दिखती है।

ऐसे रूपांतरण भी हैं जो भाषा नहीं बदलते हैं लेकिन आसान डिबगिंग के लिए अतिरिक्त जानकारी प्रदान करते हैं।

उदाहरण के लिए बैबेल-प्लगइन-ट्रांसफॉर्म-रिएक्शन-जेएसएक्स-सोर्स डिफ़ॉल्ट रिएक्ट ट्रांसपिलिंग प्रीसेट ( @babel/preset-react ) का हिस्सा है।
यह बदल देता है

<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) स्ट्रिंग के साथ जेसन को अक्षर के रूप में आयात करना ताकि भेदभाव वाले यूनियनों के साथ एक प्रकार को असाइन किए जाने पर टाइपस्क्रिप्ट बारफ न हो।
3) css/yaml और अन्य ऑब्जेक्ट जैसे सिंटैक्स आयात करना
4) ग्राफिकल प्रश्न बनाना जो गतिशील रूप से सही प्रकार बनाते हैं
5) जेएसएक्स को एचटीएमएल स्ट्रिंग्स में संकलित करना ताकि वे आंतरिक HTML इंजेक्शन हो सकें
5) tsconfig पथ के आधार पर सापेक्ष आयात के लिए पूर्ण आयात को फिर से लिखना।

यह सूची लम्बी होते चली जाती है। प्लगइन एपीआई अच्छा है। इसे उतारने के लिए धन्यवाद। "Tsconfig" का "प्लगइन्स" भाग होने से tsc वास्तव में शक्तिशाली हो जाता है। क्या कुछ बड़ा है जो हमें याद आ रहा है?

आप बहुत सारे प्रदर्शन अनुकूलन भी कर सकते हैं। मैं टाइपस्क्रिप्ट ट्रांसफॉर्मर के साथ https://github.com/atlassian-labs/compiled-css-in-js लिख रहा हूं अच्छा होगा यदि उपभोक्ताओं को इसका उपयोग करने के लिए हुप्स के माध्यम से कूदने की आवश्यकता नहीं है।

प्रिय टाइपस्क्रिप्ट टीम, कृपया इस पर अपनी एड़ी खींचना बंद करें <_<

इस पर क्या स्थिति है?

स्थिति?

दोस्तों क्या खबर है?

टाइपस्क्रिप्ट टीम ने इस विचार के खिलाफ फैसला किया है - यदि आपको लचीलेपन की आवश्यकता है या टाइपस्क्रिप्ट का उपयोग करके बेहतर देव टूलिंग हैक के बिना एक विकल्प नहीं है - इसके बजाय बेबेल के साथ जाएं और टाइपस्क्रिप्ट का उपयोग केवल टाइपचेकिंग के लिए करें

टाइपस्क्रिप्ट टीम ने इस विचार के खिलाफ फैसला किया है - यदि आपको लचीलेपन की आवश्यकता है या टाइपस्क्रिप्ट का उपयोग करके बेहतर देव टूलिंग हैक के बिना एक विकल्प नहीं है - इसके बजाय बेबेल के साथ जाएं और टाइपस्क्रिप्ट का उपयोग केवल टाइपचेकिंग के लिए करें

लेकिन क्या होगा अगर मुझे टाइप-चेकिंग के लिए कुछ हैक्स चाहिए? मैं एक छोटा ट्रांसफार्मर लिखता हूं जो कुछ जादू करता है:

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

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

फ़ंक्शन check विशिष्ट प्रकार-गार्ड फ़ंक्शन में परिवर्तित हो गया! मैं इसे बाबेल के साथ कैसे बना सकता हूं? वर्तमान में, मुझे ttypescript का उपयोग करना चाहिए ...

टाइपस्क्रिप्ट टीम ने इस विचार के खिलाफ फैसला किया है - यदि आपको लचीलेपन की आवश्यकता है या टाइपस्क्रिप्ट का उपयोग करके बेहतर देव टूलिंग हैक के बिना एक विकल्प नहीं है - इसके बजाय बेबेल के साथ जाएं और टाइपस्क्रिप्ट का उपयोग केवल टाइपचेकिंग के लिए करें

वास्तव में भविष्य में इसके समर्थित होने की चर्चा है। उस ने कहा, यह वास्तव में पहले से ही समर्थित है। टाइपस्क्रिप्ट कंपाइलर एपीआई ट्रांसफॉर्मर का समर्थन करता है, और कस्टम कंपाइलर लिखना _really_ सरल है जो कोड की केवल कुछ पंक्तियों में ट्रांसफॉर्मर का उपयोग करता है।

लेकिन इसे आसान बनाने के लिए, आप 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

टाइपस्क्रिप्ट check प्रकार की परिभाषा पर निर्भर कोड को संकलित करेगा और फिर आप इसे बैबेल का उपयोग करके जेनरेट कोड से बदल देंगे।

@ जस्ट-बोरिस मैं बैबेल में सामान्य प्रकार <T> तक कैसे पहुँच प्राप्त कर सकता हूँ?

यह धागा काफी दोहराव और ऑफ-टॉपिक हो रहा है। @RyanCavanaugh शायद इस धागे को तब तक लॉक किया जाना चाहिए, जब तक आपके पास इस विषय पर कोई अपडेट न हो।