Typescript: Dukungan Plugin untuk Transformer Kustom

Kami tidak berencana untuk mengekspos sistem plugin kompiler dalam jangka pendek. Transformasi diekspos sebagai bagian dari API publik seperti yang Anda catat, dan kami sedang dalam proses menulis dokumentasi dan sampel untuk ini.

Saya tidak ingin memiliki API plugin yang terbuka. Sebagai gantinya, saya lebih suka cara mendaftarkan transformasi kustom saya hanya dengan menentukannya di tsconfig.json daripada harus menggunakan TS-Compiler API. Karena menggunakan TS-Compiler API menyiratkan bahwa saya tidak dapat lagi menggunakan alat baris perintah tsc yang selanjutnya dapat menyiratkan bahwa itu tidak lagi terintegrasi dengan baik ke dalam alat pembangunan dan alur kerja yang ada.

sesuatu yang update tentang dokumentasi dan sampel? @mhegazy

@MichaReiser Anda dapat menulis kompiler sederhana berdasarkan API (contoh di sini ). Kami benar-benar menggunakan TS sangat banyak dalam Yahoo Finance dan API publik transformator sangat mengagumkan.

Itulah beberapa trafo yang kami tulis setelah dipublikasikan:
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 jika Anda memerlukan bantuan untuk mendokumentasikan/mengumpulkan sampel

@longlho
Terima kasih untuk sampel Anda.

Itulah yang sedang saya lakukan saat ini. Namun, tidak memungkinkan untuk menggunakan alat pembangunan lain yang dibuat untuk TypeScript, misalnya pemuat paket web, pemuat lelucon. Selain itu, bagaimana saya bisa menggunakan salah satu plugin Anda bersama dengan salah satu plugin saya ketika masing-masing dari kita menggunakan frontend yang berbeda?

Oleh karena itu, saya percaya bahwa pendekatan saat ini adalah awal yang baik tetapi tidak cukup untuk ekosistem plugin. Karena menggunakan plugin terlalu banyak usaha bagi pengguna dan membutuhkan lebih dari sekedar menulis kode transformasi untuk penulis.

Saya percaya sistem plugin seperti Babel sangat penting untuk TypeScript jika tujuannya adalah untuk mendorong komunitas membuat dan menggunakan transformer kustom.

@MichaReiser ya. Saya tidak mengatakan itu cukup untuk ekosistem, cukup baik untuk langkah pertama menuju itu.

Saya ingin menambahkan dukungan untuk transformasi dalam gulp-typescript, tetapi saya ingin mencegah semua plugin TypeScript (untuk gulp, webpack dll) mengusulkan API yang berbeda. Dan TypeScript mungkin menambahkan cara yang berbeda untuk mengonfigurasi ini nanti. Jadi apakah Anda saat ini memiliki rencana untuk menambahkan ini dalam waktu dekat atau jauh?

Hai semua, saya mencoba menulis preprosesor, tetapi tidak ada yang keluar :[

Sebenarnya, saya punya dua pertanyaan:

• Bagaimana cara membuat AST-fragmen dari string?
• Bagaimana cara menambahkan impor?

// 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;
}());

Contoh Sederhana: https://github.com/RubaXa/typescript-api-questions/tree/master/import-add

️ ️ ️
@longlho , @mhegazy Bisakah Anda memberikan petunjuk?

@RubaXa Karena Anda menambahkan deklarasi impor dalam transformasi, itu tidak terikat atau tipe dicentang. Karena tidak terikat atau jenis dicentang, kami tidak dapat menyelesaikan __LIB__ dalam ekspresi Anda ke __LIB__ dalam deklarasi.

Salah satu opsi adalah menggunakan impor namepace alih-alih impor default, sehingga emisi Anda seperti:

import * as __LIB__ from "@external/lib"

Karena tidak ada aliasing yang bisa terjadi.

Yang lainnya memegang pengidentifikasi yang dihasilkan untuk deklarasi impor, sesuai dengan zip terlampir

@RubaXa jika tujuan Anda adalah untuk meneruskan seluruh objek modul, Anda mungkin ingin menggunakan sintaks import * as __LIB__ from "@external/lib" (yang tidak memerlukan aliasing) dan bukan import __LIB__ from "@external/lib" karena yang terakhir mengimpor default ekspor daripada seluruh objek modul.

ya kami melakukan import * as foo di transformator modul CSS kami juga untuk mencegah aliasing. Meskipun akan menyenangkan untuk memanfaatkannya untuk menyejajarkan ekspor bernama tertentu

@rbuckton O, terima kasih banyak!
Masih tertarik dengan cara membuat fragmen AST sewenang-wenang dari string?

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

Inilah yang saya harapkan dari dukungan transformator dan alur kerja akan berperilaku seperti di TypeScript.

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

Saya juga sangat tertarik dengan fitur ini.

seperti yang disebutkan @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.

senang melihat masukan dari para ahli/kompiler TypeScript DEV.

Sepertinya seseorang telah membungkus TypeScript untuk mengekspos fungsi ini. https://github.com/cevek/ttypescript

Juga sepertinya ts-loader memilikinya: https://www.npmjs.com/package/ts-loader#getcustomtransformers -----before-transformerfactory--after-transformerfactory----

Saya pikir ini adalah sesuatu yang bisa mendarat di TypeScript 2.8 rilis atau setidaknya di roadmap di beberapa titik, @ahejlsberg @mhegazy @DanielRosenwasser bagaimana menurut Anda? Dengan cara ini, trafo khusus mungkin lebih populer dan karenanya lebih kuat. Memiliki opsi untuk plugin di transfromer dari perspektif tsconfig.json akan sangat menyederhanakan hidup.

Kami tidak memiliki rencana untuk mengekspos plugin dalam jangka pendek, seperti yang disebutkan sebelumnya.

@mhegazy Apakah ini keputusan yang dipertimbangkan atau di luar cakupan hanya karena minat komunitas yang rendah?

Saya tidak mengatakan itu. kami ingin mempertahankan API publik/biaya pemeliharaan yang kecil serta fleksibilitas dalam mengubah cara pembangunan didorong ke depan, dan keduanya dipengaruhi oleh model plugin.

Tolong, hentikan fragmentasi api plugin transformator. Stabilkan api plugin di atas api trafomer dan paparkan di tsconfig.json.

ts-loader , parcel-plugin-typescript , rollup-plugin-typescript2 , ts-transformer-keys , ttypescript dan lain-lain.

Masing-masing menyediakan metode pendaftaran plugin khusus dan format titik masuk plugin khusus. Ini adalah cara untuk plugin ts neraka.

Sekarang cevec/ttypescript mendukung semua format plugin transformator umum. Ini adalah pembungkus drop-in di atas semua modul TypeScript dan perintah tsc, tsserver (hanya patch ts.createProgram runtime kecil). Webpack ts-loader dan rollup-plugin-typescript2 dapat dengan mudah dikonfigurasi dengan ttypescript.

TTypescript menyarankan format plugin transformator universal, tetapi transformator yang ada juga didukung.

{
    "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/**/*"]
}

Ada berita tentang ini? Sepertinya saya seperti penulis TypeScript entah bagaimana tidak ingin mengizinkan trafo khusus pada Vanilla TypeScript - sayang sekali, itu akan menjadi fitur yang luar biasa.

mereka tidak ingin api/permukaan lain dipertahankan karena takut menyebabkan kesulitan memecahkan barang-barang di internal. Ironisnya, semua solusi plugin pihak ke-3 ini, karena tidak ada standar oleh tim ts, semuanya agak berbeda dan pada akhirnya akan rusak.

mereka tidak ingin api/permukaan lain dipertahankan karena takut menyebabkan kesulitan memecahkan barang-barang di internal.

Setelah 3 tahun bekerja dengan TypeScript dan mengamati evolusinya, saya sampai pada kesimpulan sederhana. Microsoft memiliki TypeScript open-source dalam arti _code_, tetapi tidak dalam arti _process_. Dalam sebagian besar kasus, proyek sumber terbuka kurang lebih didorong oleh komunitas baik dalam keputusan maupun dalam pengkodean , dan ini seharusnya menjadi cara alami untuk berkembang. Apakah Anda ingat garpu IO.js dari node.js? Komunitas menyadari bahwa kepentingan perusahaan tidak begitu selaras dengan model tata kelola open source yang umum, dan mereka hanya bercabang. Saya harap ini tidak akan terjadi untuk TypeScript, tetapi Microsoft harus memperhitungkan kemungkinan ini.
Untuk lebih jelasnya, saya tidak menyalahkan para pengembang, bagaimanapun, mereka melakukan pekerjaan dengan baik, sungguh.
Hanya 2c saya, maaf untuk OT.

Microsoft memiliki TypeScript open-source dalam arti kode, tetapi tidak dalam arti proses.

Saya sepenuh hati tidak setuju dengan ini. Saya tidak pernah bekerja untuk Microsoft, tetapi saya memiliki pengaruh langsung pada beberapa fitur TypeScript selama 4 tahun terakhir. Saya mewakili perpustakaan sumber terbuka yang dibangun di TypeScript, dan kami mengatur untuk melakukan beberapa percakapan langsung, tetapi semua "debat" fitur apa pun dilakukan secara terbuka, di depan umum, di sini. Tim inti menerbitkan catatan rapat desain mereka. Satu-satunya "orang dalam" yang saya dapatkan, mewakili perpustakaan sumber terbuka, adalah kesempatan untuk memperdebatkan kasus saya untuk beberapa fitur secara langsung dan bertemu dengan tim inti. Itu membuat saya menyadari bahwa tim bertindak sebagai sebuah tim. Salah satu fitur yang kami bicarakan, Anders pada dasarnya mengatakan masalahnya terlalu sulit dan akan membutuhkan banyak waktu untuk menyelesaikannya dan memecahkan masalah "nyata" yang dihadapi orang. Itu dua tahun lalu dan di TypeScript 3.0 kami akhirnya mendapatkannya. Tetapi komunitas memiliki suara dalam proses desain, tetapi seperti komunitas mana pun, kami memiliki suara dan berbagai suara, dan tidak ada tim di mana pun yang dapat menyenangkan semua orang, dan jika mereka melakukannya, TypeScript akan menjadi alat yang _benar-benar_ buruk.

Anda juga ingin memberi label tim inti "Microsoft". Tim inti adalah tim Microsoft paling sedikit yang pernah saya temui. Mereka bertempur untuk mendapatkan kendali penuh atas irama rilis mereka, setelah mereka didirikan dengan kendali penuh atas konten rilis mereka. Mereka juga memperjuangkan keterbukaan dan transparansi. Perjuangan untuk pindah ke GitHub dari CodePlex. Memang mereka tidak lagi unik di Microsoft karena beberapa tim lain telah mengadopsi model mereka, tetapi sejauh yang saya ketahui, merekalah yang memulai semuanya, dengan tim VSCode mengikuti dengan cepat setelahnya.

Jadi hanya karena tim inti memilih dan memilih pertempuran mereka, berpegang pada Prinsip Desain mereka tidak berarti bahwa komunitas tidak memiliki suara, tetapi sebagai suara kita menderita gangguan kepribadian ganda psikotik. Kami adalah pelanggan yang sulit untuk dilayani.

Pemahaman saya adalah bahwa ini sama dengan #16607, atau apakah ini akan mencapai tujuan yang berbeda? Sebagai penulis plugin yang sangat baru, saya juga ingin melihat ini terbuka - termasuk ketika bekerja dengan TypeScript menggunakan plugin Babel.

@mrmckeb masalah ini adalah untuk menstandardisasi dan mengekspos transformasi AST TypeScript, yang sudah ada, sementara masalah terkait tampaknya membahas seluruh transformasi file dalam cakupan yang sangat luas (tidak terdefinisi).

Saya ingin menambahkan 2 sen saya di sini. Beberapa dari Anda mungkin pernah mendengar tentang proyek brilian babel-plugin-macros . Pada dasarnya, alih-alih memiliki ribuan plugin Babel yang berbeda, hanya ada satu yang kemudian didukung oleh kode pengguna untuk melakukan transformasi. Sistem yang sangat transparan tanpa perlu mengacaukan konfigurasi setiap saat. Ini sangat bagus untuk proyek seperti CRA yang mendukung makro tetapi melarang konfigurasi tambahan.

Hari ini saya telah membuka diskusi tentang bagaimana mungkin membawa ini ke dunia TypeScript. Jika Anda memiliki wawasan, silakan datang dan berbagi.

Pada akhirnya, saya berharap bahwa jika kita berhasil, tidak akan ada kebutuhan untuk ini karena hanya satu transformasi yang diperlukan.

@FredyC itu proyek yang keren, tetapi kami perlu masalah ini diselesaikan agar dapat dengan mudah menyuntikkan sesuatu seperti itu ke dalam kompiler ketika hanya menggunakan tsc . Misalnya, dengan babel-plugin-makros masih perlu ditentukan dalam .babelrc dan akan lebih baik untuk menentukan sesuatu seperti itu di TypeScript di tsconfig.json .

Sebenarnya, apakah Anda menyarankan bahwa akan menyenangkan untuk memiliki perilaku seperti babel-plugin-macro yang dibangun ke dalam TypeScript dan tidak ada konfigurasi yang diperlukan? Itu mungkin bagus, tetapi secara pribadi saya lebih suka solusi yang dapat dikonfigurasi yang memungkinkan menentukan trafo khusus di tsconfig.json dan kemudian versi babel-plugin-makro yang mendukung node ast script dapat ditentukan.

@dsherret Ya, saya tidak berharap itu akan menjadi bagian dari TypeScript itu sendiri. Namun, saya dapat membayangkan bahwa setelah transformasi siap, akan mudah untuk menyiapkan tsc -seperti pembungkus kecil yang hanya akan menyuntikkan transformasi untuk makro dan sisanya dapat dilakukan dari kode pengguna.

Sunting: Sebenarnya, pembungkus kecil sudah ada di sana, dengan https://github.com/cevek/ttypescript yang disebutkan di atas, akan mudah untuk diinstruksikan untuk menggunakannya bersama dengan plugin makro universal dan ini adalah win-win.

Saya hanya perlu menemukan orang yang berpengalaman dalam transformasi TypeScript untuk menemukan beberapa prototipe dasar. Saya dapat berdiskusi dan berbicara, tetapi menerapkannya di atas keahlian saya saat ini.

mereka tidak ingin api/permukaan lain dipertahankan karena takut menyebabkan kesulitan memecahkan barang-barang di internal.

Setelah 3 tahun bekerja dengan TypeScript dan mengamati evolusinya, saya sampai pada kesimpulan sederhana. Microsoft memiliki TypeScript open-source dalam arti _code_, tetapi tidak dalam arti _process_. Dalam sebagian besar kasus, proyek open-source kurang lebih didorong oleh komunitas baik dalam _decisions_ maupun dalam _coding_, dan ini seharusnya menjadi cara alami untuk berkembang. Apakah Anda ingat garpu IO.js dari node.js? Komunitas menyadari bahwa kepentingan perusahaan tidak begitu selaras dengan model tata kelola open source yang umum, dan mereka hanya bercabang. Saya harap ini tidak akan terjadi untuk TypeScript, tetapi Microsoft harus memperhitungkan kemungkinan ini.
Untuk lebih jelasnya, saya tidak menyalahkan para pengembang, bagaimanapun, mereka melakukan pekerjaan dengan baik, sungguh.
Hanya 2c saya, maaf untuk OT.

Saya setuju. Jelas bahwa meskipun ada minat yang kuat dari komunitas, pengembang hanya menolak gagasan trafo/makro kustom tanpa benar-benar memberikan alasan penolakan kecuali sesuatu di baris "Orang akan menyalahgunakannya", yang juga terdengar menyinggung komunitas karena itu menyiratkan itu adalah komunitas pengembang berkualitas rendah.

Saya akan menerima penolakan jika pembenaran yang masuk akal selain "Kami tidak akan melakukannya begitu saja" dapat diberikan, tetapi tampaknya terlepas dari semua permintaan dari komunitas, belum ada yang berusaha untuk menyediakannya.

Saya pikir ini adalah kritik yang tidak adil @pietrovismara. Saya setuju bahwa ini adalah fitur yang harus dimiliki, tetapi ini bukan "Microsoft" yang memblokir fitur ini. Tim, seperti yang saya pahami, mengatakan bahwa ini tidak mudah untuk didukung dan itulah mengapa mereka belum menambahkan fitur seperti itu.

Sekali lagi, saya menginginkan fitur ini sama seperti orang lain - tetapi kita perlu mendiskusikan masalah ini dengan menggunakan fakta. Faktanya, tim belum siap mendukungnya. Jadi mari terus menyuarakan minat, tetapi juga menjaga percakapan di jalur yang benar.

@mrmckeb Jika itu masalahnya saya bisa memahaminya. Saya pasti melewatkan deklarasi seperti itu dalam arus besar komentar yang terkandung dalam masalah ini. Tidak bermaksud menyinggung siapa pun, hanya mencoba memancing jawaban yang jelas dari pengelola agar, seperti yang Anda katakan, menjaga percakapan di jalur yang benar.

Tidak apa-apa, ini membuat frustrasi karena dukungan untuk ini tidak ada - seperti yang saya katakan, saya merasakannya, dan kami selalu diminta untuk beberapa jenis solusi untuk modul CSS di CRA sekarang karena kami memiliki dukungan TypeScript. Saya berharap itu akan segera datang, tetapi saya juga mengerti bahwa itu membuka area risiko yang sangat besar bagi tim.

... masih menunggu :(

ya, masih menunggu ..., tapi menunggu apa, sesuatu telah dilakukan?

Apakah ada solusi yang lebih baik daripada ttypescript sekarang?
Apakah pengembang TypeScript akhirnya berencana untuk mendukung plugin?

Anda dapat membuat kompiler Anda sendiri ;-)

Ada berita tentang topik itu? Tampaknya bagi saya bahwa komunitas telah menggunakan fitur ini cukup luas untuk duduk, mengumpulkan umpan balik, dan akhirnya menambahkan dukungan untuk transformer ke file konfigurasi. Bahkan ada banyak implementasi untuk digunakan sebagai referensi.

Sudah lebih dari 2 tahun (wow!)*. Apakah orang-orang terbuka untuk memikirkan kembali pro dan kontra untuk membuka plugin untuk transformer?

Saya merasa kekhawatiran awal yang ada sejak dulu, seperti kurangnya dokumentasi tentang API, dan harus mendukung penyatuan kode pengguna <-> transformer <-> API, tidak relevan lagi. Dukungan plugin terbuka telah menghasilkan keajaiban untuk paket seperti babel: perkembangan melalui kolaborasi. Saya pribadi dapat membuktikan Babel secara khusus, setelah menggunakannya secara ekstensif.

Integrasi transformer "hanya berfungsi" yang lebih mudah seperti TypeScript -is _would_ menyenangkan. Paket ini secara khusus saya lihat memiliki pengaruh revolusioner yang tenang pada TypeScript secara keseluruhan. Kontrak yang benar-benar kuat! 😃.

Saya pikir percakapan tentang pro dan kontra akan membantu menghilangkan kekesalan atau perbedaan dalam hal ini. Saya merasa bahwa masalah zombie ini akan terus berlanjut sampai hal itu terjadi - jujur ​​saja.

* Dan sementara itu seseorang membuat fitur untuk TS sebagai gantinya ( ttypescript ). Saya telah menggunakan ini untuk sukses.

@DanielRosenwasser Saya melihat bahwa ada "Selidiki API plugin TypeScript" pada rencana iterasi 3.5 (dan pekerjaan itu sudah dimulai).
Apakah poin itu membahas tentang apa yang dibahas dalam edisi ini? Kurangnya tautan ke suatu masalah membuat saya menganggap itu terlalu banyak WIP untuk membagikan apa pun tentangnya?

Saya pikir pekerjaan harus dilakukan untuk menambahkan dukungan penuh untuk parser Babel, yang mencakup penambahan fitur yang diperlukan untuk Babel untuk mendukung analisis statis TypeScript (mis. beberapa transformasi file atau ketergantungan pada banyak file selama transformasi). Daripada harus menduplikasi sintaks/mengubah plugin Babel ke yang setara dengan TypeScript.

jika Anda memiliki masalah dengan instruksi berikut, beri tahu saya, saya akan dengan senang hati membantu

mengingat kelalaian tim desain, inilah solusinya

kita akan memanfaatkan tslint dan kemampuan memperbaiki kodenya

dalam contoh berikut kita akan melakukan transformasi tipe-ke-kode , dalam bentuk paling dasar

kita akan menggunakan dekorator sebagai penanda tempat dalam kode yang perlu ditulis ulang

dalam kasus kami, dekorator adalah fungsi palsu yang satu-satunya tujuannya adalah

• untuk menandai tempat transformasi
• dan untuk menangkap jenis yang akan menjadi sumber informasi untuk generator

untuk tujuan demonstrasi, kita akan membuang nama dan jenis properti antarmuka sebagai string biasa, ke dalam kelas yang mendasarinya

langkah-langkah berikut hanya untuk pengguna windows, jika Anda bukan salah satunya, semoga Tuhan membantu Anda:

1. mulai VSCode Anda
2. instal ekstensi berikut: https://github.com/Microsoft/vscode-typescript-tslint-plugin
3. tutup VSCode Anda
4. pergi ke folder pilihan Anda
5. jalankan git clone https://github.com/zpdDG4gta8XKpMCd/code-gen.git
6. masuk ke folder code-gen : cd ./code-gen
7. Lari
   
   
   
   • 1-install.bat
   
   
   • 2-build.bat
   
   
   • 3-install-some-more.bat
   
   
   • 4-try.bat
   
   
8. amati instance VSCode dibuka
9. pergi ke test.ts ( Ctrl + P -> test.ts )
10. perhatikan antarmuka berikut, itu akan menjadi sumber untuk pembuat kode

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

1. perhatikan fungsi berikut, yang terdiri dari dekorator hantu yang akan kita gunakan sebagai penanda

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

1. perhatikan situs penulisan ulang, tempat kami ingin memasukkan beberapa kode yang dihasilkan secara otomatis berdasarkan antarmuka dan dekorator penanda

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

1. amati garis berlekuk-lekuk di bawah @gen<Data>()
   

2. pilih Quick fix... -> Needs a rewrite, wanna fix?
   

3. amati kode yang dibuat secara otomatis:
   

untuk referensi disini adalah source code generator yang bisa anda temukan di 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 , terima kasih telah berbagi konsep Anda - tetapi harap bersikap sopan.

mengingat kelalaian tim desain, inilah solusinya

Ini bukan cara yang tepat untuk mengatasi TypeScript karena tidak mengimplementasikan _feature_ yang Anda (dan banyak orang lain, termasuk saya) ingin miliki. Ini bukan cacat besar, dan tidak mencerminkan "kelalaian". Harap hormat.

oh tolong jangan menganggapnya pribadi, ini hanya cara saya selalu memulai keluhan saya, saya memiliki kepribadian yang sangat masam (kondisi medis) dan ini yang terbaik yang bisa saya keluarkan dari diri saya, saya sangat menyesal

kalian tidak akan berhenti mengejutkanku

• apa yang Anda lihat adalah sepotong kode yang tampaknya mampu memecahkan masalah utama hari ini dengan nyaman (tanpa trik, tanpa peretasan)
• solusi ini adalah panggilan untuk membangunkan tim desain, dan seperti yang kita lihat sebelumnya ketika komunitas akan berbelok ke arah yang salah, tim desain ada di sana untuk segera mengatasinya: #4212,
• jadi jika mereka peduli, mereka dapat melakukannya dengan benar lebih cepat sampai terlambat, atau jika tidak, kita bebas untuk menggali ke arah ini dan itu tidak akan menjadi masalah bagi mereka di kemudian hari
• jadi nada umpan balik saya adalah sesuatu yang tidak pantas, tetapi semua nada yang sesuai dari Anda tidak menghasilkan apa-apa sejak 2 Maret 2017 (lebih dari 2 tahun), dan ya, Anda bisa menunggu 2 tahun lagi

@zpdDG4gta8XKpMCd Apa yang telah Anda sumbangkan untuk implementasi yang sebenarnya? TypeScript adalah sumber terbuka; Saya yakin mereka akan serius mempertimbangkan permintaan tarik jika Anda membuatnya (bahkan sebagian).

Menyalahkan kekasaran Anda pada kondisi medis tidak dapat diterima; itu adalah kata-kata yang Anda ketik dan secara sukarela memilih untuk mengklik "komentar". Tidak ada kondisi medis yang membuat Anda melakukan itu. Bicaralah, mungkin, bukan mengetik. Anda juga memiliki kesempatan untuk mengedit komentar Anda untuk menghapusnya, namun Anda belum melakukannya.

Jika Anda membutuhkan trafo khusus _now_, Anda dapat menggunakan Babel. Itu dapat menghapus anotasi tipe dari hampir semua TypeScript, sambil memungkinkan transformasi sintaksis semudah yang Anda inginkan. Sebagai bonus, ini juga lebih cepat.

Saya sarankan Anda berhenti berkomentar sebelum Anda dikeluarkan dari repositori Microsoft secara permanen. Saya tahu jika itu adalah repo saya, Anda akan berada di jerami terakhir Anda.

ok, Anda menendang saya keluar, lalu apa
bisakah aku kembali? apakah saya bisa membuat akun baru?
Apakah menurut Anda saya terlalu peduli dengan akun ini?

lagi pula, ya, saya mencoba permintaan tarik, sayangnya itu tidak layak karena alasan berikut:

1. ada kategori masalah tertentu yang boleh Anda pecahkan, yang agak sepele dan kurang menarik, sesuatu yang serius seperti ini - dan Anda tidak

2. karena Anda tidak dapat menyelesaikannya sendiri, masalah seperti ini (bahkan memiliki 224 jempol) dapat menunggu bertahun-tahun jika pernah dipertimbangkan sama sekali

3. untungnya Anda dapat melakukan sesuatu hari ini dengan menggunakan cara apa pun yang Anda miliki dan mulai membuat perbedaan yang dapat dilihat, maka sarannya (jangan salahkan saya karena tidak melakukan apa-apa)

@zpdDG4gta8XKpMCd sebanyak yang Anda tahu Saya telah menjadi penggemar sinis selama bertahun-tahun, saya harus setuju dengan orang lain di sini - kita harus menjaga percakapan tetap sopan dan hormat. Itu selalu pengingat yang baik bahwa setiap orang yang melacak masalah ini ingin membuat proyek lebih baik .

@Janpot Yup, ini sangat WIP, meskipun ketika @rbuckton kembali, dia mungkin dapat memberikan beberapa detail lebih lanjut tentang status.

Saat kami menyelidiki poin plugin (seperti yang saya singgung dalam rencana iterasi 3.5), saya pikir mengekspos kait yang lebih mudah untuk transformer kustom adalah skenario utama yang ingin kami pertimbangkan. Alasan mengapa kami tidak melakukan ini secara langsung adalah karena kami mungkin memiliki pekerjaan yang lebih luas yang mencakup hal ini. Dengan kata lain, mungkin ada sesuatu yang lebih luas dari sekedar pra dan pasca transformator.

@DanielRosenwasser tidak ada yang sinis di dalamnya, saya hanya mengatakan 2 kata dan kemudian saya berkata saya sangat menyesal tentang itu

lagi pula, intinya adalah saya pikir kita semua setuju bahwa ada bagian yang baik dari frustrasi yang sehat atas bagaimana keadaan berjalan, dan kami tidak menyalahkan Anda, kami mengerti apa yang mendorong proyek ini

tetapi jika kita melihat dari sudut pandang kita pasti ada yang harus disalahkan, karena membiarkan masalah seperti ini duduk selama bertahun-tahun hanya mengumpulkan acungan jempol, itulah yang membuat kita berhenti menjadi lebih produktif

saya yakin ada alasan untuk menundanya dan fokus pada beberapa hal lain terlebih dahulu, jadi saya pikir akan lebih baik jika Anda memberi tahu audiens Anda mengapa fitur tertentu yang sangat diinginkan tidak dapat dipenuhi, itu dapat menurunkan tingkat frustrasi, katakan:

• kami tidak dapat mengimplementasikan fitur ini karena A, BC dan kebutuhan D, E, dan F dilakukan terlebih dahulu

jadi saya kira saya mengacu pada percakapan ini: https://github.com/Microsoft/TypeScript/issues/30696#issuecomment -478799258

Mengacungkan jempol tidak membuat sumber daya baru keluar begitu saja, membuat keputusan yang rumit dan sulit menjadi sederhana dan mudah, mengubah prioritas bisnis yang ada, menghentikan proyek dalam penerbangan, mengabaikan prioritas pekerjaan lain, menyebabkan proposal yang terlalu ambisius menjadi tercakup dengan baik, atau mengubah saran dengan dampak luas dan permanen menjadi fokus dan dapat dipertahankan.

Saya tidak meminta maaf karena kami melakukan (atau mengizinkan PR untuk , yang Anda keluhkan di #30696) di muka, pekerjaan yang baik dan sederhana yang dipahami dengan baik sebelum pekerjaan yang sangat kompleks dan pemeliharaan tinggi seperti ini. Seharusnya tidak sulit untuk menebak mengapa kita rela membiarkan seseorang masuk dan memperbaiki keran yang bocor sementara rencana untuk merombak ruang bawah tanah dan menambahkan lantai lain di atas rumah masih sedang dikerjakan.

@zpdDG4gta8XKpMCd Mengapa Anda harus menyalahkan seseorang? Mengapa Anda tidak menyalahkan diri sendiri sejak awal bahwa Anda belum membuat PR untuk memperbaiki masalah ini? Atau setidaknya beberapa tulisan konstruktif tentang cara mendekatinya dari sudut pandang implementasi?

Ya ampun, bahkan setelah tulisan transparan yang baru saja Anda tautkan, Anda memutuskan untuk menyodok beruang lagi setelah hanya 2 minggu? Coba bayangkan berada di posisi itu dengan memiliki 1500+ tugas dan Anda harus memilih beberapa di antaranya. Di tim kami, kami memindahkan sekitar 100 tugas dan cukup berjuang. Tidak bisa membayangkan itu akan 15 kali lebih banyak

@FredyC demi Tuhan, lihat solusi saya sebelum mengatakan saya tidak melakukan apa-apa

ya, saya tidak melakukan permintaan tarik formal karena:

1. saya tidak sampai pada level untuk membuat yang bagus

2. untuk yang sederhana, ada garis panjang persetujuan, dan dibutuhkan kerja keras untuk menjaga permintaan tarik yang dibuat 2 tahun yang lalu up to date dengan basis kode saat ini, saya tidak punya banyak waktu

3. masalah tertentu bahkan tidak akan dipertimbangkan, mengingat pertimbangan desain besar yang hanya disadari oleh sedikit orang seperti anders hejlsberg

Anda tidak dapat menghilangkan bagian frustrasi, dan saya tidak sendirian di sini

kita tahu ada faktor-faktor ini yang berperan:

• desain besar bahasa
• anggaran / sumber daya / politik di dalam MS
• keinginan masyarakat

Saya akan lebih senang jika pengambilan keputusan dengan campuran bahan-bahan ini sedikit lebih jelas

aku sudah selesai, ini sudah terlalu jauh, maaf untuk semua orang yang perasaannya terluka, aku tidak akan mengatakan sepatah kata pun

kelanjutan dari https://github.com/Microsoft/TypeScript/issues/14419#issuecomment -483920640

opsi lain adalah menggunakan deklarasi fungsi sendiri sebagai penanda, yang di bawah ini adalah implementasi dari generator kode untuk fungsi yang namanya dimulai dengan toRandom...

sumber informasi untuk generator adalah jenis hasil dari fungsi

begini Cara kerjanya:

1. perhatikan garis berlekuk-lekuk di bawah fungsi yang dimulai dengan toRandom...
   
2. jelajahi pilihan Anda:
   
3. lakukan perbaikan cepat
   
4. amati hasilnya:
   

di sini adalah kode codeGenRule.ts yang melakukannya

sebagai bonus, implementasi ini hanya akan menimbulkan masalah linting jika kode fungsi saat ini tidak cocok dengan kode yang seharusnya dibuat

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 Saya yakin masalah ini lebih tentang memiliki cara yang lebih mudah untuk mencolokkan trafo khusus saat memancarkan? Mantan. menentukan transformasi di tsconfig.json sehingga dapat digunakan dengan tsc daripada menggunakan api . Apakah Anda menginginkan perubahan/perbaikan kode khusus di editor?

Saya belum pernah menggunakannya sama sekali, tetapi saya pikir apa yang Anda bicarakan mungkin sudah dimungkinkan dengan plugin layanan bahasa (saya pikir dengan mengganti getCodeFixesAtPosition pada layanan bahasa dan memasukkan tindakan kode Anda sendiri... tidak yakin) https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

Atau mungkin saya salah paham?

Baik. itulah yang dulu saya pikirkan

saya pikir cara untuk menentukan transformasi kustom saya melalui tsconfig.json akan menjadi mimpi yang menjadi kenyataan

tetapi kemudian saya menyadari bahwa saya lebih menyukai solusi saya

inilah jalan pemikiran saya:

• saya membutuhkan generator kode yang dapat dikonfigurasi dan dapat dipasang
• TypeScript tidak memiliki hal seperti itu berguna
• di sisi lain saya tahu bahwa tslint (meskipun disusutkan pada akhir 2019) adalah platform plugin yang layak untuk TypeScript yang memiliki cara untuk plugin dan mengonfigurasi kode Anda dengan kebebasan besar
• ternyata ia memiliki semua yang saya butuhkan:
  
  
  
  • dapat dipasang dan dikonfigurasi
  
  
  • dengan semua UI yang diperlukan
  
  
  • memberi saya API untuk TypeScript
  
  
  • memiliki beberapa tambahan kecil
  
  

mengingat semua itu saya tidak dapat melihat diri saya menulis sesuatu yang menggunakan layanan bahasa TypeScript, karena:

• laptop saya hanya dapat menampung banyak layanan bahasa TypeScript, dan beberapa di antaranya sudah:
  
  
  
  • salah satu dari vscode
  
  
  • salah satu dari tslint
  
  

dan saya tidak ingin menambahkan satu lagi di atas itu

saya berharap saya memiliki cara yang lebih baik untuk memasukkan trafo kode saya, tetapi kami memiliki apa yang kami miliki

dan inilah cara kami melakukan makro: #4892

• laptop saya hanya dapat menampung banyak layanan bahasa TypeScript, dan beberapa di antaranya sudah:

  • satu per dari vscode
  • satu oleh tslint

@zpdDG4gta8XKpMCd Saya percaya semuanya harus menggunakan layanan bahasa yang sama. Jadi Anda akan memiliki layanan bahasa tunggal dan kemudian plugin tslint bersama dengan plugin Anda akan mem-proxy itu.

Btw, apa yang Anda coba lakukan di sini pasti dapat dilakukan dengan plugin layanan bahasa sederhana karena itulah yang dilakukan di sini .

Bagaimanapun, mari kita coba untuk menjaga percakapan di sini pada topik dan hanya tentang transformer kustom sebagai bagian dari build dengan tsc daripada perubahan kode editor/layanan bahasa. Kebanyakan orang mencari solusi untuk melakukan transformasi di seluruh proyek dan melakukan itu di dalam editor bukanlah solusi yang layak (terutama karena melakukan transformasi pada saat itu mengalahkan tujuan menggunakannya). Idealnya apa yang harus diterapkan di sini seharusnya tidak ada hubungannya dengan editor/tsserver atau layanan bahasa.

terima kasih atas masukan yang berharga, saya akan mempertimbangkannya

saya tidak setuju dengan Anda tentang menjaga percakapan hanya tentang trafo khusus sebagai bagian dari build dengan tsc , karena

• permintaan asli seperti yang tertulis tidak spesifik dalam bentuk apa yang akan dikirim, itu hanya menyatakan bahwa mereka tidak perlu harus
  > duplikat seluruh baris perintah tsc hanya untuk menambahkan satu transformator
• lebih dari 2 tahun diskusi ini telah menarik sedikit perhatian dari banyak orang yang tampaknya tidak terlalu peduli tentang bagaimana transformator diimplementasikan, asalkan ada solusi, cara kerjanya dan mudah digunakan
• juga, tim tslint melakukan pekerjaan yang baik dalam membangun infrastruktur untuk plugin, tidak menggunakannya hanya membuang-buang usaha, asalkan secara de facto itu satu-satunya platform yang diakui secara resmi di luar TypeScript yang berhubungan dengan TypeScript
• juga, kita semua setuju bahwa bahkan jika transformer pernah menemukan jalan mereka ke bahasa itu tidak akan terjadi dalam waktu dekat, tetapi orang-orang di sini (termasuk saya) membutuhkannya seperti kemarin
• terakhir, karena tidak banyak alternatif yang lebih baik, mengapa kita tidak mempertimbangkan setidaknya apa yang kita miliki?

saran saya dengan jelas diberi label sebagai solusi (sementara tim desain meluangkan waktu untuk berpikir lebih keras tentang solusi yang tepat), jadi mengapa tidak?

jika Anda bersikeras kami harus melakukannya di tempat lain, silakan angkat bicara

tetapi untuk mengatasi kekhawatiran Anda dalam melakukan

mengubah seluruh proyek

tslint melakukan hal itu dengan argumen --fix untuk cli

@zpdDG4gta8XKpMCd --fix akan memperbarui kode TypeScript di tempatnya. Masalah ini adalah tentang melakukan transformasi selama memancarkan (jadi perubahan hanya berakhir di file JavaScript akhir). Lihat PR masalah yang dirujuk (#13940):

Sejak #13764 telah mendarat, mudah untuk menulis trafo khusus. Namun, jika saya memahami API dengan benar, diperlukan untuk menduplikasi seluruh baris perintah tsc hanya untuk menambahkan satu transformator. Hal ini menyebabkan ketidakcocokan karena ini, tergantung pada TypeScript, aplikasi tidak mendukung fitur yang sama seperti alat baris perintah tsc.

Dengan kata lain, masalah itu membawa CustomTransformers (klik tautan itu dan lihat di mana itu digunakan di API), tetapi untuk menggunakannya tsc perlu diduplikasi entah bagaimana atau dibungkus, itulah yang ttypescript tidak. Paragraf kedua kemudian berbicara tentang bagaimana ini akan baik karena akan terintegrasi dengan baik di alat build yang ada (karena menggunakan transformer khusus akan ditangani oleh tsc daripada alat build yang berbeda melakukannya dengan cara yang berbeda).

Saya pikir akan lebih produktif untuk membuka masalah baru dengan masalah Anda dengan perbaikan kode atau menginginkan cara yang lebih mudah untuk menghasilkan kode TypeScript dalam kode TypeScript. Saya tidak yakin persis apa kekhawatiran itu karena saya pikir banyak yang sudah mungkin hari ini, tetapi apa yang telah Anda diskusikan adalah bagaimana melakukan perbaikan/tindakan kode, yang tampaknya seperti subjek yang tidak terkait bagi saya.

Saya pikir pertanyaan utama yang harus dijawab dalam utas ini adalah apa yang dibahas Daniel—"mungkin ada sesuatu yang lebih luas dari sekadar pra dan pasca-transformator"—dan seperti apa solusi untuk membuat bagian bangunan ini nantinya.

kamu tidak jelas

saya adalah orang yang mengerti dan menghargai hal-hal sederhana

masalah saya bahwa saya sedang berurusan dengan sekitar 3500+ proyek file, di mana 15% tidak perlu ditulis dan dikelola dengan tangan dan ada sekitar 5% dari hal-hal serupa di atasnya yang akan datang

pada saat yang sama saya tahu ada API yang dapat melakukannya untuk saya, tetapi itu sangat setengah matang sehingga saya tidak pernah bisa membenarkan waktu saya untuk menanganinya agar benar-benar matang

jadi ketika saya datang ke sini saya pikir ini adalah tempat yang tepat untuk membicarakannya, dan ternyata mungkin ada solusi cepat dan sederhana

nasib buruk beberapa orang yang datang ke sini untuk membahas beberapa hal yang jauh lebih baik

oke, luar biasa!

dan tidak, saya tidak akan membuka masalah baru hanya untuk menunjukkan kepada orang-orang sekali lagi bagaimana tslint dapat memecahkan salah satu masalah utama, saya melakukan pekerjaan saya, saya selesai

Memiliki transformasi yang dapat dikonfigurasi di luar kotak akan menyenangkan. Saya mencoba mengatasi masalah string dalam kode l10n dan i18n . Saya dapat memanfaatkan alat seperti tslint dengan aturan khusus untuk ekstraksi, tetapi opsi saya untuk mengubah kode terbatas, kecuali saya menggunakan sesuatu seperti ttypescript , tetapi itu bermasalah karena aplikasi saya sedang dikerjakan adalah aplikasi sudut yang tidak dikeluarkan. Itu hanya memaksa saya untuk menambahkan lapisan demi lapisan alat build. Dengan kecepatan pengembangan, seluruh tumpukan menjadi sangat berbahaya.

Kami sedang mengembangkan kerangka kerja dan kami saat ini menggunakan ttypescript untuk mengakses informasi tingkat tipe saat runtime, alangkah baiknya jika opsi plugins pada kompiler resmi akhirnya

Saya sedang berlibur sekarang tetapi akan melihat minggu depan ketika saya kembali

Pada hari Minggu, 21 Juli 2019 pukul 17.54 Giorgio Boa [email protected]
menulis:

@longlho https://github.com/longlho Anda membuat banyak ast yang hebat
transformer, saya butuh bantuan Anda 👍
Saya benar-benar ingin memodifikasi metadata dekorator sebelum kompilasi Angular.
Tujuan saya adalah memodifikasi simpul ini
Komponen({ pemilih: 'standar' ... }) menjadi Komponen({ pemilih: 'kustom'
... })
Saya membuat repo github untuk mengujinya
https://github.com/gioboa/ng-ts-transformer . Saya pikir itu mungkin tapi
tanpa dokumentasi saya butuh bantuan. 🙏 Terima kasih.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVWQ2ZLODN5WZHJKTDN5
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCfer5A
.

Saya telah berkontribusi untuk membuat perpustakaan untuk membuat tiruan nyata dari antarmuka tanpa proxy . Saya merekomendasikan untuk menggunakan ttypescript untuk saat ini tetapi akan menyenangkan untuk memiliki cara yang terintegrasi dengan TypeScript

Saya sangat ingin melihat fitur ini terjadi. Saya cukup yakin ini adalah satu-satunya hal yang berdiri di antara TypeScript dan beberapa inovasi terbesar yang mungkin dihasilkannya.

TypeScript adalah kontribusi besar untuk pengembangan frontend, tetapi juga menghambat inovasi lebih lanjut…
Jangan merusak semantik. Tidak ada plugin ATM yang tidak dapat merusak semantik; dan tidak ada plugin yang diizinkan sama sekali :man_shrugging: Mengapa?
Ada plugin yang sangat bagus, tapi. Setiap plugin harus menghormati (kunci) tokenisasi kata dan instation AST)… , cara yang sangat sulit untuk melakukan sesuatu di dalam.
Ini tidak begitu sulit. Ini tidak mudah, tetapi proyek babel menunjukkan bahwa itu mungkin.
Bahkan hampir sepele bagi babel untuk memperkenalkan semantik baru atau bahkan frasa sintaksis.

Saya tidak berharap dari TypeScript untuk mengizinkan semantik. (tentu saja saya tidak mengharapkan perubahan sintaks!)
Apa yang saya inginkan dari kompiler adalah pergeseran dalam beberapa kasus, seperti (mungkin hanya tipe) preeval.
Seperti jika saya memiliki fungsi yang diambil, seperti route atau message atau sesuatu, kompiler dapat melakukan preeval dan (oh, tolong, pada fase satu) periksa kebenarannya.

Jika Anda membaca paragraf saya sebelumnya aneh. Apa itu tsx dan semua Bereaksi baik?

Tidak ada Bereaksi, tidak ada aliran, tidak ada TypeScript sama sekali, hampir tidak sekilas.

Tolong. Saya sangat memahami melihat-berdiri dengan hati-hati di semua ini; tapi seperti yang kita pelajari dari IE5.5+; memblokir tidak ada jalan ke depan.

Jika ada yang perlu diperbaiki, itu masih mesin tata letak. D.Knuth adalah guenie yang merancang semua bagian yang hilang 50 tahun yang lalu. Mengapa kita tidak memilikinya hari ini?? :-)
Tolong, beri tahu orang-orang untuk menghentikan CSS dalam kejahatan JS.

Tolong. Buka TS untuk kecerdasan semantik ; seperti fungsi dengan input string statis, memberikan petunjuk jenis untuk sisanya; menganalisis string input const aktual…
Sedikit Contoh:

• Bentuk pengembalian panggilan GraphQL
• Bentuk masukan internasional
• …lebih banyak_
  Tolong. Tidak diperlukan perubahan semantik. Semuanya akan bekerja seperti yang diinginkan. Sesuatu yang lebih dapat diperiksa pada waktu pembuatan. Itu saja! :kelinci:

menabrak

Saya bereksperimen dengan menulis transformasi TS untuk pengoptimalan core-js import - polyfilling otomatis untuk lingkungan target, seperti @babel/preset-env dan @babel/runtime , tetapi tanpa babel . Ini bisa sangat membantu sebagian besar pengembang TS. Tetapi tanpa dukungan transformasi khusus dari kotak tanpa alat tambahan seperti ttypescript , kemungkinan menggunakan transformasi itu akan sangat terbatas, jadi saya tidak yakin itu masuk akal.

Saya telah bereksperimen dengan ide seperti itu - https://github.com/webschik/typescript-polyfills-generator .
Saya pikir Transformers API akan membuka kemungkinan untuk mengeluarkan babel dari rantai pengembangan. Saya pikir banyak pengembang tidak ingin menggunakan keduanya, tetapi mereka masih membutuhkan plugin seperti @babel/preset-env .

Saat ini kami telah meluncurkan skrip kompiler kustom kami sendiri (menggunakan API kompiler TypeScript) karena batasan ini. Kami secara singkat melihat ttypescript , tetapi keinginan untuk beralih dari kompiler Vanilla TypeScript ke ekstensi kompiler TypeScript sama sekali tidak ada.

Akan luar biasa jika trafo khusus didukung di tsconfig.json. Sulit untuk menulis skrip yang hanya mem-parsing tsconfig, mendeklarasikan transformer, lalu menjalankan kompiler; atau, lebih buruk, untuk benar-benar mencoba dan mencoba mengimplementasikan kembali fitur dasar kompiler, seperti menonton file, dalam skrip khusus.

Orang lain telah menggemakan sentimen ini, tetapi memungkinkan kemudahan mengintegrasikan transformer kustom ke dalam kompiler akan mengambil beban signifikan dari tim pengembangan TypeScript dan memungkinkan inovasi dan momentum maju tambahan dengan bahasa ini dari komunitas.

Contoh ekosistem plugin yang sangat sukses adalah komunitas plugin Serverless Framework. Tim pengembangan tidak dapat memenuhi permintaan untuk pengembangan fitur, dan plugin memungkinkan cara yang bagus untuk memungkinkan integrasi fitur baru (mungkin eksperimental) tanpa perlu membuka PR atau mempermudah produk inti dengan fitur yang mungkin atau mungkin tidak memberikan nilai kepada basis pengguna yang lebih luas.

Saya sedang membangun perpustakaan dan saya memiliki dekorator di dalamnya yang sangat cocok untuk saya dan yang saya andalkan. Saya menyadari beberapa waktu lalu bahwa dekorator membuat perpustakaan saya tidak goyang. Setelah melihat ke dalamnya, saya sampai pada kesimpulan bahwa transformer dapat membantu saya mengubah dekorator itu menjadi kode yang dapat digoyahkan saat kompilasi. Sangat disayangkan bahwa saya tidak dapat mendefinisikannya dalam saluran saya. Saya harap Anda akan segera mengatasi masalah ini, hanya ingin memberikan 2 sen saya pada kasus penggunaan yang akan sangat membantu.

Demi kepentingan membuat TypeScript mendukung trafo khusus tanpa program pembungkus dan instruksi yang rumit, saya telah menulis sebuah alat yang disebut ts-patch ( npm github )

Cukup instal ts-patch (secara global atau lokal) dan jalankan ts-patch install untuk menambal TypeScript. Anda juga dapat menentukan direktori penginstalan TypeScript dan/atau mengaktifkan kegigihan, yang mempertahankan tambalan jika TS diperbarui atau diinstal ulang. (detail: ts-patch /? )

Logika tambalan sebagian besar didasarkan pada ttypescript. (Terima kasih banyak untuk pekerjaan hebat cevek!) Ini ditulis dengan cara yang dapat dengan mudah ditambahkan ke proses instalasi paket npm. Ini juga mudah untuk di-unpatch.

Agar jelas, ini secara langsung menambal file yang relevan dalam TypeScript itu sendiri dan bukan pembungkus. Cukup jalankan tambalan setelah instalasi ketergantungan, dan TypeScript akan siap untuk transformator.

Semoga ini bisa membantu beberapa orang!

Demi kepentingan membuat TypeScript mendukung trafo khusus tanpa program pembungkus dan instruksi yang rumit, saya telah menulis sebuah alat yang disebut ts-patch ( npm github )

Cukup instal ts-patch (secara global atau lokal) dan jalankan ts-patch install untuk menambal TypeScript. Anda juga dapat menentukan direktori penginstalan TypeScript dan/atau mengaktifkan kegigihan, yang mempertahankan tambalan jika TS diperbarui atau diinstal ulang. (detail: ts-patch /? )

Logika tambalan sebagian besar didasarkan pada ttypescript. (Terima kasih banyak untuk pekerjaan hebat cevek!) Ini ditulis dengan cara yang dapat dengan mudah ditambahkan ke proses instalasi paket npm. Ini juga mudah untuk di-unpatch.

Agar jelas, ini secara langsung menambal file yang relevan dalam TypeScript itu sendiri dan bukan pembungkus. Cukup jalankan tambalan setelah instalasi ketergantungan, dan TypeScript akan siap untuk transformator.

Semoga ini bisa membantu beberapa orang!

bisakah ini diangkat sebagai PR untuk menambah/membahas dukungan yang tepat? :)

Hai. Untuk apa nilainya, ada bundler yang disebut fuse-box yang membuatnya sangat mudah untuk menambahkan trafo khusus. Versi 4.0-nya akan segera hadir... jadi ada di antara keduanya. Tapi secara keseluruhan, saya sangat suka bundlernya. Mungkin bisa membantu Anda juga.

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

bisakah ini diangkat sebagai PR untuk menambah/membahas dukungan yang tepat? :)

Tim TS telah menyatakan bahwa mereka tidak ingin menyediakan ini sebagai fitur asli. Alasan mereka untuk keputusan itu masuk akal!

Kabar baiknya adalah karena TS adalah open source dan sudah dikompilasi dalam mode modular, ts-patch berperilaku dengan cara yang sangat mirip jika itu dibangun di dalamnya. Jadi ini tidak seperti patch bytecode yang direkayasa terbalik dengan buggy.

Jika dengan dukungan, Anda khawatir tentang itu dipertahankan, saya berencana untuk tetap saat ini dan bekerja untuk semua versi masa depan TS! Banyak infrastruktur komersial saya sudah bergantung padanya.

Sebagai catatan tambahan, saya akan segera merilis versi baru yang memungkinkan untuk mengemas beberapa plugin dengan titik masuk yang berbeda ke dalam satu paket serta beberapa pengoptimalan lain untuk meningkatkannya dan membuatnya lebih mudah digunakan.

Setelah menulis sebuah plugin, saya dapat menghargai mengapa tim ts ragu-ragu - transformator saat ini adalah langkah pasca-kompilasi. Anda mengalami masalah buruk jika Anda melakukan sesuatu yang rumit dan mulai menambahkan konten baru yang awalnya tidak terikat. Seperti berdiri, ts-node --compiler ttypescript foo.ts bekerja dengan baik. Saya lebih suka tim ts menangani plugin transformer pada langkah kompilasi yang berbeda... atau mengizinkan langkah rebinding.

Transformator arus adalah langkah pasca-kompilasi. Anda mengalami masalah buruk jika Anda melakukan sesuatu yang rumit dan mulai menambahkan konten baru yang awalnya tidak terikat.

Transformer dapat berjalan baik sebelum atau sesudah kompilasi TSC. Kedengarannya seperti yang Anda maksud adalah bahwa pemeriksa tidak memperbarui setelah memodifikasi node. Ini sebenarnya dapat dielakkan, fungsionalitasnya tidak dibuat untuk itu. Saat Anda memanggil ts.transform(), itu tidak membuat instance Program lengkap untuk Anda gunakan, jadi jika Anda ingin bekerja dengan pemeriksa, Anda harus membuatnya. Menggunakan CompilerHost, Anda dapat memuat ulang dengan file yang dimodifikasi setelah mengubah AST.

Saya belum terlalu jauh ke dalamnya, tetapi sepertinya juga dimungkinkan untuk menggunakan fungsionalitas 'watch' untuk menghindari keharusan membangun kembali seluruh instance Program setiap kali. Sederhananya, ternyata tidak _terlalu_ sulit untuk memiliki sistem Plugin yang lebih lengkap, tetapi transform tidak memiliki dukungan dalam konteks yang disediakan.

@nonara Saya telah menggunakan transformasi dengan ttypescript dan ts-loader`, keduanya memiliki titik masuk program lengkap. Masalah saya adalah jika Anda menambahkan pernyataan impor baru, "sesuatu" yang hilang dan pernyataan baru itu dihapus dari keluaran keluaran akhir. @weswigham mengatakan itu karena transformasi adalah langkah pasca-pengikatan . Solusinya tampaknya adalah membuat Program yang sama sekali baru untuk file - tetapi itu sepertinya memusingkan ketika Anda berurusan dengan hal-hal seperti ts-loader (terutama ketika dalam mode hanya-transformasi dan sepenuhnya menyembunyikan file webpack/bundler- resolver Pada akhirnya saya menjatuhkan impor dan hanya memasukkan kode yang saya butuhkan .

@MeirionHughes Ah, oke. Dalam hal ini, ya, Anda memiliki instance Program. ttypescript bekerja dengan mengaitkan createProgram untuk menambal metode emit program yang dihasilkan untuk menyertakan transformer.

• ts.emitFiles memanggil ts.transformNodes selama proses.
• ts.transformNodes dapat dipanggil dengan atau tanpa instance Program. Memanggil langsung ts.transform() melakukannya tanpa panggilan.

Jika saya memahaminya dengan benar, sepertinya masalah Anda juga terkait dengan fakta bahwa jenis & simbol telah berjalan, dan mereka tidak diperbarui setelah transformasi AST.

Hai semuanya Saya telah menulis Buku Pegangan Transformer untuk mengumpulkan semua informasi tentang transformator serta untuk mempermudah memulai.

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

Akan sangat senang jika Anda bisa meluangkan waktu sebentar 👍

@madou Saya juga menulis banyak posting di TS transformer https://levelup.gitconnected.com/writing-typescript-custom-ast-transformer-part-1-7585d6916819

Ini statusnya apa?

Sangat menyukai TypeScript, tetapi rasanya sangat kikuk ketika Anda mulai melakukan interop antara tipe statis dan runtime JS. Ada banyak plugin yang ditulis komunitas untuk membuat ini lebih baik, misalnya https://github.com/dsherret/ts-nameof , https://github.com/kimamula/ts-transformer-keys - tetapi tanpa dukungan plugin kelas satu rasanya seperti keputusan teknis yang berisiko untuk memasukkan mereka ke dalam sebuah proyek. Mengaktifkan plugin secara asli akan memungkinkan komunitas untuk bermain-main dengan fitur TypeScript yang potensial di masa depan, sebelum mereka perlu dimasukkan dalam pustaka inti.

Saya pikir tim TypeScript harus mempertimbangkan kembali argumentasi mereka. Ekosistem plugin adalah cara yang terbukti untuk memajukan bahasa, memungkinkan (dan mendorong) eksperimen (lihat Haskell dengan pragmanya).

Beberapa dari eksperimen itu akan menjadi liar dan gila, dan beberapa pada akhirnya akan stabil dan menjadi umum. Itu selalu baik untuk menyediakan kemampuan untuk mengimplementasikan fitur bahasa di ruang pengguna.

Secara umum, posisi tim TypeScript terlihat kaku yang tidak perlu.

Ada juga transformasi yang tidak mengubah bahasa tetapi memberikan informasi tambahan untuk debugging yang lebih mudah.

Misalnya babel-plugin-transform-react-jsx-source adalah bagian dari default react transpiling preset ( @babel/preset-react ).
Itu berubah

<sometag />

Ke dalam

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

Informasi ini memungkinkan react menyediakan jejak tumpukan kesalahan yang lebih baik selama pengembangan.

Untuk TypeScript tidak ada cara standar untuk mencapai hal yang sama meskipun ada transformasi open source: https://github.com/dropbox/ts-transform-react-jsx-source

Saya mengerti @mhegazy menyebutkan dua kali bahwa tim TS tidak memiliki rencana untuk memasukkan "plugin" sebagai bagian dari tsconfig. Apa alasan di balik ini?

Apakah Anda akan terbuka untuk PR? Cara ttypescript menangani transformer melalui tsconfig cukup bagus.

Kasus penggunaan:

1) menghasilkan tipe antarmuka ke skema sehingga dapat diperiksa runtime.
2) mengimpor json dengan string sebagai literal sehingga TypeScript tidak muntah ketika ditugaskan ke tipe dengan serikat yang didiskriminasi.
3) mengimpor css/yaml dan objek lain seperti sintaks
4) membuat kueri graphql yang secara dinamis membuat jenis yang tepat
5) kompilasi jsx ke string html sehingga dapat disuntikkan innerHTML
5) menulis ulang impor absolut ke impor relatif berdasarkan jalur tsconfig.

Daftarnya terus bertambah. Plugin apinya bagus. Terima kasih telah mendaratkannya. Memiliki "plugin" bagian dari "tsconfig" membuat tsc sangat kuat. Apakah ada sesuatu yang besar yang kita lewatkan?

Anda juga dapat melakukan banyak pengoptimalan kinerja. saya telah menulis https://github.com/atlassian-labs/compiled-css-in-js dengan transformer TypeScript akan keren jika konsumen tidak perlu melewati rintangan untuk menggunakannya.

Tim TypeScript yang terhormat, tolong berhenti menyeret Anda pada <_< . ini

Ini statusnya apa?

Status?

Teman berita apa?

Tim TypeScript telah memutuskan untuk menentang ide ini - jika Anda membutuhkan fleksibilitas atau alat dev yang lebih baik menggunakan TypeScript bukanlah pilihan tanpa peretasan - gunakan babel sebagai gantinya dan gunakan TypeScript hanya untuk pengecekan huruf

Tim TypeScript telah memutuskan untuk menentang ide ini - jika Anda membutuhkan fleksibilitas atau alat dev yang lebih baik menggunakan TypeScript bukanlah pilihan tanpa peretasan - gunakan babel sebagai gantinya dan gunakan TypeScript hanya untuk pengecekan huruf

Tetapi bagaimana jika saya ingin beberapa peretasan untuk pengecekan tipe? Saya menulis sebuah transformator kecil yang membuat keajaiban:

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

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

Fungsi check diubah menjadi fungsi penjaga tipe tertentu! Bagaimana saya bisa membuatnya dengan Babel? Saat ini, saya harus menggunakan ttypescript...

Tim TypeScript telah memutuskan untuk menentang ide ini - jika Anda membutuhkan fleksibilitas atau alat dev yang lebih baik menggunakan TypeScript bukanlah pilihan tanpa peretasan - gunakan babel sebagai gantinya dan gunakan TypeScript hanya untuk pengecekan huruf

Sebenarnya ada beberapa pembicaraan tentang ini menjadi didukung di masa depan. Yang mengatakan, itu benar-benar sudah didukung. API kompiler TypeScript mendukung transformer, dan _sangat_ mudah untuk menulis kompiler khusus yang menggunakan transformer hanya dalam beberapa baris kode.

Namun untuk mempermudah, Anda bisa menggunakan ttypescript atau ts-patch .

Pustaka ini sebenarnya bukan "peretasan" dalam arti bahwa mereka tidak menambah kompiler untuk menambah kemampuan transformator. Sebagai gantinya, mereka hanya mengekspos fungsionalitas yang ada dari compiler API ke tsc , membuatnya dapat digunakan melalui tsconfig.

@ilya-buligin jika saya memahami kasus penggunaan Anda dengan benar, Anda dapat mendeklarasikan konstanta ambien

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

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

TypeScript akan mengkompilasi kode dengan mengandalkan definisi tipe check dan kemudian Anda akan menggantinya dengan kode yang dihasilkan menggunakan Babel.

@just-boris bagaimana saya bisa mendapatkan akses ke tipe generik <T> di Babel?

Utas ini menjadi cukup berulang dan di luar topik. @RyanCavanaugh Mungkin utas ini harus dikunci, sampai Anda memiliki pembaruan tentang masalah ini.