Typescript: カスタムトランスフォーマーのプラグインサポート

コンパイラプラグインシステムを短期的に公開する予定はありません。 ご指摘のとおり、トランスフォームはパブリックAPIの一部として公開されており、現在、これらのドキュメントとサンプルを作成中です。

プラグインAPIを公開したくありません。 代わりに、TS-Compiler APIを使用する代わりに、tsconfig.jsonでカスタム変換を指定するだけでカスタム変換を登録する方法をお勧めします。 TS-Compiler APIを使用すると、tscコマンドラインツールを使用できなくなり、既存のビルドツールやワークフローにうまく統合されなくなる可能性があります。

ドキュメントとサンプルに関する更新はありますか？ @mhegazy

@MichaReiserは、APIに基づいた単純なコンパイラーを作成できます（サンプルはこちら）。 私たちは実際にYahooFinance内でTSを非常に頻繁に使用しており、トランスフォーマーのパブリックAPIは素晴らしいものでした。

これらは、公開後に作成したトランスフォーマーの一部です。
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
サンプルをありがとう。

それが私が現在していることです。 ただし、タイプスクリプト用に作成された他のビルドツール（Webパックローダー、jestローダーなど）を使用することはできません。 さらに、私たち一人一人が異なるフロントエンドを使用しているときに、プラグインの1つを私のプラグインと一緒に使用するにはどうすればよいですか？

したがって、現在のアプローチは良いスタートですが、プラグインエコシステムには十分ではないと思います。 プラグインを使用することはユーザーにとって非常に手間がかかり、作成者のために変換コードを書くだけでは不十分だからです。

コミュニティがカスタムトランスフォーマーを作成して使用することを奨励することが目標である場合、タイプスクリプトにはBabelのようなプラグインシステムが不可欠であると思います。

@MichaReiserうん。 私はそれが生態系にとって十分であると言っているのではなく、それへの第一歩としては十分である。

gulp-typescriptで変換のサポートを追加したいのですが、すべてのTypeScriptプラグイン（gulp、webpackなど）が異なるAPIを提案しないようにしたいです。 また、TypeScriptは、後でこれを構成するための別の方法を追加する可能性があります。 では、現在、近い将来または遠い将来にこれを追加する計画はありますか？

こんにちは、私はプリプロセッサを書こうとしましたが、何も出てきません：[

実際、2つの質問があります。

• 文字列からASTフラグメントを作成するにはどうすればよいですか？
• インポートを追加する方法は？

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

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

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

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

簡略化された例： https ：//github.com/RubaXa/typescript-api-questions/tree/master/import-add

⬆️⬆️⬆️
@ longlho 、 @ mhegazyヒントを教えていただけますか？

@RubaXaトランスフォームにインポート宣言を追加したため、バインドもタイプチェックもされません。 バインドも型チェックもされていないため、式の__LIB__を宣言の__LIB__に解決することはできません。

1つのオプションは、デフォルトのインポートの代わりに名前空間のインポートを使用することです。これにより、emitは次のようになります。

import * as __LIB__ from "@external/lib"

発生する可能性のあるエイリアシングがないため。

もう1つは、添付のzipに従って、インポート宣言用に生成された識別子を保持します

@RubaXa目標がモジュールオブジェクト全体を渡すことである場合は、$＃$ 1 import __LIB__ from "@external/lib" ＃$ではなくimport * as __LIB__ from "@external/lib"構文（エイリアシングを必要としない）を使用することをお勧めします。後者はdefaultをインポートするためです。モジュールオブジェクト全体ではなく、

ええ、エイリアシングを防ぐために、 CSSモジュールトランスフォーマーでもimport * as fooを実行しています。 それを利用して、特定の名前付きエクスポートをインライン化するのは良いことですが

@rbuckton O、どうもありがとう！
文字列から任意のASTフラグメントを作成する方法にまだ興味がありますか？

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

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

これは、トランスフォーマーのサポートとワークフローがTypeScriptでのように動作することを期待していたものです。

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

私もこの機能に非常に興味があります。

@MichaReiserが述べたように
If someone experienced has inputs on how to implement the changes, I'm willing to create a PR as it would simplify my project tremendously.

エキスパート/ typescriptコンパイラDEVからの入力を見るのが大好きです。

誰かがこの機能を公開するためにtypescriptをラップしたようです。 https://github.com/cevek/ttypescript

また、ts-loaderがそれを持っているように見えます： https ：//www.npmjs.com/package/ts-loader#getcustomtransformers ----- before-transformerfactory--after-transformerfactory ----

これは、typescript 2.8リリース、または少なくともある時点でのロードマップに到達する可能性があるものだと思います。 @ ahejlsberg @mhegazy @DanielRosenwasserどう思いますか？ このように、カスタムトランスはより人気があり、したがってより強力になる可能性があります。 tsconfig.jsonの観点からtransfromerにプラグインするオプションがあると、作業が大幅に簡素化されます。

前述のように、プラグインを短期的に公開する予定はありません。

@mhegazyそれは考慮された決定ですか、それともコミュニティの関心が低いという理由だけで範囲外ですか？

私はそう言いませんでした。 小さなパブリックAPI /保守性のコストと、ビルドの進め方を柔軟に変更できるようにしたいと考えています。これらは両方ともプラグインモデルの影響を受けます。

トランスフォーマープラグインのAPIフラグメンテーションを停止してください。 トランスフォーマーAPIの上にプラグインAPIを安定させ、tsconfig.jsonで公開します。

ts-loader 、 parcel-plugin-typescript 、rollup -plugin-typescript2 、 ts-transformer-keys 、 ttypescriptなど。

それぞれが、カスタムプラグイン登録方法とカスタムプラグインエントリポイント形式を提供します。 それはtsプラグイン地獄への道です。

現在、cevec / ttypescriptは、すべての一般的なトランスフォーマープラグイン形式をサポートしています。 これは、すべてのtypescriptモジュールとtsc、tsserverコマンド（小さなランタイムts.createProgramパッチ）の上にあるドロップインラッパーです。 Webpack ts-loaderとrollup-plugin-typescript2は、ttypescriptを使用して簡単に構成できます。

TTypescriptはユニバーサルトランスフォーマープラグインフォーマットを提案していますが、既存のトランスフォーマーもサポートされています。

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

これに関するニュースはありますか？ TypeScriptの作者はどういうわけかバニラTypeScriptでカスタムトランスフォーマーを許可したくないようです-それは残念です、それは素晴らしい機能でしょう。

内部で物事を壊すのが困難になることを恐れて、別のAPI /サーフェスを維持することを望んでいません。 皮肉なことに、これらのサードパーティのプラグインソリューションはすべて、ts-teamによる標準がないため、すべて多少異なり、最終的には機能しなくなります。

内部で物事を壊すのが困難になることを恐れて、別のAPI /サーフェスを維持することを望んでいません。

タイプスクリプトを使って3年間作業し、その進化を観察した後、私は簡単な結論に達しました。 Microsoftは、_code_の意味でのオープンソースのTypescriptを持っていますが、_process_の意味ではありません。 ほとんどの場合、オープンソースプロジェクトは、意思決定とコーディングの両方で多かれ少なかれコミュニティ主導であり、これは進化するための自然な方法であるはずです。 node.jsのIO.jsフォークを覚えていますか？ コミュニティは、会社の利益が一般的なオープンソースガバナンスモデルとそれほど一致していないことに気づき、彼らは単に分岐しました。 TypeScriptでこれが起こらないことを願っていますが、Microsoftはこの可能性を考慮に入れる必要があります。
明確にするために、私は開発者を非難していません、とにかく、彼らは本当に素晴らしい仕事をしています。
ちょうど私の2c、OTをごめんなさい。

Microsoftは、コードの意味ではオープンソースのTypescriptを持っていますが、プロセスの意味ではありません。

私はこれに心から反対します。 私はMicrosoftで働いたことがありませんが、過去4年間、TypeScriptのいくつかの機能に直接影響を与えてきました。 私はTypeScriptに組み込まれたオープンソースライブラリを代表していて、直接会話をするように手配しましたが、機能に関するすべての「討論」は、ここで公開されました。 コアチームは、設計会議のメモを公開します。 私が得た唯一の「インサイダー」は、オープンソースライブラリを表しており、いくつかの機能について自分の主張を直接議論し、コアチームに会う機会でした。 チームがチームとして機能していることに気づきました。 私たちが話し合った機能の1つであるアンダース氏は、基本的に問題は難しすぎて、問題を解決して人々が直面する「実際の」問題を解決するには多くの時間がかかると述べました。 それは2年前のことで、TypeScript3.0ではようやく入手できました。 しかし、コミュニティは設計プロセスに発言権を持っていますが、他のコミュニティと同様に、私たちはさまざまな意見を表明しており、誰もが喜ぶチームはどこにもありません。もしそうなら、TypeScriptは_本当に_悪いツールになります。

また、コアチームに「Microsoft」というラベルを付けます。 コアチームは、私が今まで出会った中で最も少ないマイクロソフトチームでした。 彼らは、リリースコンテンツの完全な制御に基づいて設立された後、リリースのリズムを完全に制御するために戦いました。 彼らはまた、開放性と透明性のために戦った。 CodePlexからGitHubに移行するための戦い。 確かに、他のいくつかのチームがモデルを採用しているため、Microsoftではそれほどユニークではありませんが、私が知る限り、すべてを開始したのはVSCodeチームでした。

したがって、コアチームが戦いを選んで選択したからといって、彼らの設計原則に固執することは、コミュニティに声がないことを意味するのではなく、声として私たちは精神病性の多重人格障害に苦しんでいます。 私たちはサービスを提供するのが難しい顧客です。

私の理解では、これは＃16607と同じですか、それとも別の目標を達成するでしょうか？ ごく最近のプラグインとして、私自身も、Babelプラグインを使用してTypeScriptを操作する場合を含め、これが公開されることを望んでいます。

@mrmckebこの問題は、すでに存在するタイプスクリプトAST変換を標準化して公開するためのものですが、リンクされた問題は、非常に広い（未定義の）スコープでのファイル全体の変換について議論しているようです。

ここに2セントを追加したいと思います。 素晴らしいプロジェクトbabel-plugin-macrosについて聞いたことがある方もいらっしゃるかもしれません。 基本的に、何千もの異なるBabelプラグインを使用する代わりに、ユーザーコードを使用して変換を実行するプラグインのみを使用できます。 常に構成をいじる必要のない、非常に透過的なシステム。 これは、マクロをサポートしているが追加の構成を禁止しているCRAのようなプロジェクトに特に適しています。

今日、私はこれをTypeScriptの世界に持ち込む方法についての議論を始めました。 何か洞察があれば、ぜひ来て共有してください。

最終的には、何らかの形で成功した場合、必要な変換は1つだけなので、これは必要ないことを願っています。

@FredyCはすばらしいプロジェクトですが、 tscのみを使用する場合に、このようなものをコンパイラに簡単に挿入するには、この問題を解決する必要があります。 たとえば、babel-plugin-macrosを使用する場合でも、 .babelrcで指定する必要があり、 tsconfig.jsonのtypescriptでそのようなものを指定すると便利です。

実際、TypeScriptにbabel-plugin-macroのような動作が組み込まれていて、構成が不要であるといいと思いますか？ それはいいかもしれませんが、個人的には、 tsconfig.jsonでカスタムトランスフォーマーを指定できる構成可能なソリューションを好みます。次に、typescriptastノードをサポートするバージョンのbabel-plugin-macrosを指定できます。

@dsherretええ、TypeScript自体の一部になるとは思いません。 ただし、変換の準備ができたら、 tscのような小さなラッパーを簡単に準備でき、マクロの変換のみを挿入し、残りはユーザーコードから実行できると想像できます。

編集：実際には、小さなラッパーはすでに存在します。上記のhttps://github.com/cevek/ttypescriptを使用すると、ユニバーサルマクロプラグインと一緒に使用するように指示するのは簡単で、Win-Winです。

Typescript変換に精通している人を見つけて、基本的なプロトタイプを作成する必要があります。 話し合ったり話したりすることはできますが、それを実装することは私の現在のスキルセットを上回っています。

内部で物事を壊すのが困難になることを恐れて、別のAPI /サーフェスを維持することを望んでいません。

タイプスクリプトを使って3年間作業し、その進化を観察した後、私は簡単な結論に達しました。 Microsoftは、_code_の意味でのオープンソースのTypescriptを持っていますが、_process_の意味ではありません。 ほとんどの場合、オープンソースプロジェクトは_decisions_と_coding_の両方で多かれ少なかれコミュニティ主導であり、これは自然な進化の方法であるはずです。 node.jsのIO.jsフォークを覚えていますか？ コミュニティは、会社の利益が一般的なオープンソースガバナンスモデルとそれほど一致していないことに気づき、彼らは単に分岐しました。 TypeScriptでこれが起こらないことを願っていますが、Microsoftはこの可能性を考慮に入れる必要があります。
明確にするために、私は開発者を非難していません、とにかく、彼らは本当に素晴らしい仕事をしています。
ちょうど私の2c、OTをごめんなさい。

同意します。 コミュニティからの強い関心にもかかわらず、開発者は、「人々はそれを誤用する」という行の何かを除いて、拒否の理由を実際に提供することなく、カスタムトランス/マクロのアイデアを単に拒否していることは明らかです。それが意味するように、それは低品質の開発者のコ​​ミュニティです。

「私たちは単純にやらない」以外の合理的な正当化が提供されれば、私は拒否を受け入れますが、コミュニティからのすべての要求にもかかわらず、まだ誰もそれを提供する努力をしていません。

これは不当な批判@pietrovismaraだと思います。 これは必須の機能であることに同意しますが、これは「Microsoft」がこの機能をブロックしているわけではありません。 チームは、私が理解しているように、これをサポートするのは簡単ではないと言っています。そのため、チームはまだそのような機能を追加していません。

繰り返しになりますが、私は他の誰よりもこの機能が必要ですが、事実を使用してこの問題について議論する必要があります。 事実は、チームがまだそれをサポートする準備ができていないということです。 ですから、関心を表明し続けるだけでなく、会話を正しい軌道に乗せましょう。

@mrmckebその場合、私はそれを理解することができます。 その時、私はこれらの問題に含まれるコメントの大きな流れの中でそのような宣言を見逃したに違いありません。 あなたが言ったように、会話を正しい軌道に乗せるために、マンテナーから明確な答えを引き起こそうとしているだけで、誰かを怒らせるつもりはありませんでした。

大丈夫です。これがサポートされていないのはイライラします。私が言ったように、私はそれを感じています。TypeScriptがサポートされるようになった今、CRAではCSSモジュールの何らかのソリューションが常に求められています。 すぐに来ることを願っていますが、それがチームにとって大きなリスク領域を開くことも理解しています。

... まだ待っている ：（

うん、まだ待っている...しかし、何を待っている、何かが行われていますか？

現在、 ttypescriptよりも優れた解決策はありますか？
TypeScript開発者は最終的にプラグインをサポートすることを計画していますか？

あなたはあなた自身のコンパイラを作成することができます;-)

このトピックに関するニュースはありますか？ コミュニティはこの機能を十分に活用して、座ってフィードバックを収集し、最終的に構成ファイルにトランスフォーマーのサポートを追加したようです。 参照として使用する実装もたくさんあります。

2年以上経ちました（すごい！）*。 人々は、変圧器用のプラグインを開くことの賛否両論を再考することにオープンですか？

APIに関するドキュメントの不足や、ユーザーコード<->トランスフォーマー<-> APIのメッシュ化をサポートする必要があるなど、以前から存在していた最初の懸念は、もはや関連性がなくなったように感じます。 オープンプラグインのサポートは、babel：コラボレーションによる進歩のようなパッケージで驚異的な効果を発揮しました。 私はそれを広範囲に使用したことで、特にバベルを個人的に証明することができます。

typescriptのようなトランスフォーマーのより簡単な「正しく機能する」統合は素晴らしいでしょう。 特にこのパッケージは、typescript全体に革命的な影響を与えていると私は考えています。 真の強力な契約！ 😃

長所と短所についての会話は、これに関する落胆や違いを払拭するのに役立つと思います。 正直なところ、このゾンビの問題はそのようなことが起こるまで続くと感じています。

*その間に、誰かが代わりにTSの機能を作成します（ ttypescript ）。 私はこれを成功に使用しました。

@DanielRosenwasser 3.5イテレーションプランに「InvestigateTypeScriptプラグインAPI」があることを確認しました（その作業はすでに開始されています）。
その点は、この問題で議論されていることを処理しますか？ 問題へのリンクがないため、WIPが多すぎて、まだ問題について何かを共有できないと思いますか？

Typescript静的分析をサポートするためにBabelに必要な機能を追加することを含め、Babelパーサーの完全なサポートを追加する作業を行う必要があると思います（たとえば、複数のファイル変換または変換中の複数のファイルへの依存）。 構文を複製したり、BabelプラグインをTypescriptの同等のものに変換したりする必要はありません。

次の手順で問題が発生した場合は、お知らせください。喜んでサポートさせていただきます。

設計チームの完全な過失を考えると、ここに回避策があります

tslintとそのコード修正機能を利用します

次の例では、最も基本的な形式で、タイプからコードへの変換を行います。

書き直す必要のあるコード内の場所のマーカーとしてデコレータを使用します

私たちの場合、デコレータは偽の関数であり、その唯一の目標は

• 変容の場所をマークする
• ジェネレータの情報源となるタイプをキャプチャします

デモンストレーションの目的で、インターフェイスのプロパティの名前とタイプをプレーンな文字列として基になるクラスにダンプします。

次の手順は、Windowsユーザーのみを対象としています。ユーザーがいない場合は、神があなたを助けてくれるかもしれません。

1. VSCodeを開始します
2. 次の拡張機能をインストールします： https://github.com/Microsoft/vscode-typescript-tslint-plugin
3. VSCodeを閉じます
4. 選択したフォルダに移動します
5. git clone https://github.com/zpdDG4gta8XKpMCd/code-gen.gitを実行します
6. フォルダに移動code-gen ： cd ./code-gen
7. 走る
   
   
   
   • 1-install.bat
   
   
   • 2-build.bat
   
   
   • 3-install-some-more.bat
   
   
   • 4-try.bat
   
   
8. 開かれたVSCodeのインスタンスを観察します
9. test.tsに移動します（ Ctrl + P -> test.ts ）
10. 次のインターフェースに注意してください。これがコードジェネレーターのソースになります。

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

1. 次の関数に注意してください。これは、マーカーとして使用するファントムデコレータで構成されています。

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

1. インターフェイスとマーカーデコレータに基づいて自動生成されたコードをプッシュしたい書き換えのサイトに注意してください

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

1. @gen<Data>()の下の波線を観察します
   

2. Quick fix...を選択-> Needs a rewrite, wanna fix?
   

3. 自動生成されたコードを確認します。
   

ここでの参照は、 codeGenRule.tsにあるジェネレーターのソースコードです。

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

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

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

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

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

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

@ zpdDG4gta8XKpMCd 、あなたのコンセプトを共有してくれてありがとう-しかし、礼儀正しくしてください。

設計チームの完全な過失を考えると、ここに回避策があります

これは、あなた（および私を含む他の多くの人）が望んでいる_機能_を実装しないためのTypeScriptに対処するための適切な方法ではありません。 これは大きな欠陥ではなく、「過失」を反映していません。 敬意を表してください。

ああ、個人的には受け取らないでください、これは私がいつも苦情を始める方法です、私は非常に酸っぱい性格（病状）を持っています、そしてこれは私が自分自身から搾り出すことができる最高です、私は非常に申し訳ありません

あなた方は私を驚かせることをやめないでしょう

• 表示されているのは、今日の主要な問題を快適に（トリックやハッキングなしで）解決できると思われるコードです。
• この回避策は設計チームへの目覚めの呼びかけであり、コミュニティが間違った方向に向きを変えようとしていた前に起こったことを見て、設計チームはすぐにそれに対処するためにそこにいました：＃4212、
• ですから、彼らが気にかけているのであれば、手遅れになるまでかなり早くそれを行うことができます。そうでない場合は、私たちはこの方向に自由に掘り下げることができ、将来的には問題になりません。
• ですから、私のフィードバックの口調は不適切なものでしたが、2017年3月2日（2年以上）以降、適切な口調で何も得られませんでした。はい、さらに2年待つことができます。

@ zpdDG4gta8XKpMCd実際の実装に向けて何に貢献しましたか？ TypeScriptはオープンソースです。 プルリクエストを作成した場合（部分的にでも）、プルリクエストを真剣に検討することは間違いありません。

病状であなたの無礼を非難することは容認できません。 それらはあなたがタイプし、「コメント」をクリックすることを自発的に選んだ単語です。 どんな病状もあなたにそれをさせません。 話す、多分、タイプしないでください。 コメントを編集して削除する機会もありましたが、まだそうしていません。

カスタムトランスフォーマーが_今_必要な場合は、Babelを使用できます。 ほぼすべてのTypeScriptから型注釈を削除できると同時に、構文変換を簡単に行うことができます。 ボーナスとして、それはまたより速いです。

Microsoftのリポジトリから永久に追い出される前に、コメントをやめることをお勧めします。 それが私のレポだったとしたら、あなたは最後の藁にいるでしょう。

わかりました、あなたは私を追い出しました、それから何
戻ってきてもいいですか？ 新しいアカウントを作成できますか？
私はこのアカウントを気にしすぎていると思いますか？

とにかく、はい、プルリクエストを試しましたが、残念ながら、次の理由で実行できません。

1. あなたが解決することを歓迎している問題の特定のカテゴリーがあります、それはかなり些細で興味が少ないです、このような深刻なものは何でも-そしてあなたはそうではありません

2. 自分で解決することはできないので、このような問題（224の親指を立てていても）は、考えたとしても何年も待つことができます。

3. 幸いなことに、あなたは今日あなたが持っている手段を使って何かをすることができ、見ることができる違いを生み出し始めることができます、それ故に提案（何もしないことで私を責めないでください）

@ zpdDG4gta8XKpMCdあなたが知っている限り、私は何年にもわたって冷笑的なテイクのファンでした、私はここで他の人に同意しなければなりません-私たちは会話を礼儀正しくそして敬意を持って保つ必要があります。 この問題を追跡しているすべての人がプロジェクトをより良くしたいと思っていることを常に忘れないでください。

@Janpotうん、それは非常に仕掛品ですが、 @ rbucktonが戻ってきたときに、彼はステータスに関する詳細を提供できる可能性があります。

プラグインポイントを調査するとき（3.5反復計画でほのめかしたように）、カスタムトランスフォーマーのより簡単なフックを公開することが検討したい主要なシナリオだと思います。 私たちが必ずしもこれを完全に行うとは限らない理由は、これを包含するより広範な作業があるかもしれないからです。 言い換えれば、トランスフォーマーの前後だけでなく、もっと広いものがあるかもしれません。

@DanielRosenwasserそこにはそれほど冷笑的なものはありません、私は2つの言葉だけを言いました、そしてそれから私はそれについて深く申し訳ありませんと言いました

とにかく、ポイントは、物事がどのように進むかについて健康的な欲求不満のかなりの部分があることに私たち全員が同意していると思います、そして私たちはあなたにそれを非難しません、私たちはこのプロジェクトを推進するものを理解しています

しかし、私たちの角度から見ると、誰かが責任を負う必要があります。なぜなら、このような問題を何年にもわたって親指を立てるだけで放置することが、生産性の向上を妨げるからです。

最初にそれを延期して他のことに集中する理由があると確信しているので、特定の非常に必要な機能を実行できない理由を視聴者に知らせた方がよいと思います。これにより、フラストレーションの程度を下げることができます。

• A、BCのため、この機能を実装できません。最初にD、E、Fを実行する必要があります。

だから私はこの会話を参照していると思います： https ：//github.com/Microsoft/TypeScript/issues/30696#issuecomment -478799258

親指を立てても、新しいリソースが空から生まれたり、複雑で難しい意思決定が単純かつ簡単になったり、既存のビジネスの優先順位が変更されたり、進行中のプロジェクトが停止したり、他の作業の優先順位が下がったり、野心的な提案が範囲を広げたりすることはありません。広範囲にわたる永続的な影響を与える提案を変更して、集中して維持できるようにします。

このような非常に複雑でメンテナンスの多い作業に先立って、よく理解された適切で単純な作業を前もって行っていること（または、PRを許可していること）について謝罪することはありません。 地下室を改造して家の上に別の物語を追加する計画がまだ検討されている間に、なぜ誰かが入って漏れた蛇口を修理することをいとわないのかを推測するのは難しいことではありません。

@ zpdDG4gta8XKpMCdなぜ誰かを責める必要があるのですか？ そもそも、この問題を解決するためのPRを行っていないことを自分のせいにしてみませんか？ または、実装の観点からそれにアプローチする方法について、少なくともいくつかの建設的な記述がありますか？

ああ、その透明な書き込みの後でさえ、あなたはちょうどリンクしただけで、あなたはたった2週間後に再びクマを突くことに決めましたか？ 手元に1500以上のタスクがあるその位置にいることを想像してみてください、そしてあなたはそれらのいくつかを選ばなければなりません。 私たちのチームでは、約100のタスクを実行し、かなり苦労しています。 15倍になるとは想像できません😮

@FredyC神のために、私は何もしていないと言う前に私の回避策を見てください

はい、私は正式なプルリクエストを行っていません。理由は次のとおりです。

1. 私は良いものを作るためのレベルに達していません

2. 単純なものの場合、承認には長い時間がかかり、2年前に作成されたプルリクエストを現在のコードベースで最新の状態に保つには多大な作業が必要です。あまり時間がありません。

3. アンダース・ヘルスバーグのような少数の人々だけが知っている壮大な設計上の考慮事項を考えると、特定の問題は考慮されません。

あなたは欲求不満の部分を取り除くことはできません、そして私はここで一人ではありません

これらの要因が関係していることはわかっています。

• 言語の壮大なデザイン
• MS内の予算/リソース/政治
• コミュニティの願い

これらの材料の組み合わせによる意思決定が少し明確になれば、私はもっと幸せになるでしょう

終わった、行き過ぎだ、気持ちが傷ついたみんなにごめんなさい、一言も言わない

https://github.com/Microsoft/TypeScript/issues/14419#issuecomment-483920640の続き

もう1つのオプションは、関数宣言自体をマーカーとして使用することです。以下は、名前が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で変換を指定して、APIを使用するのではなくtscで使用できるようにします。 エディターでカスタムコードの変更/修正が必要ですか？

私はそれらをまったく使用していませんが、あなたが話していることは、言語サービスプラグインですでに可能であると思います（言語サービスでgetCodeFixesAtPositionをオーバーライドし、独自のコードアクションを挿入することで...確かではありませんが） https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

それとも私は誤解していますか？

正しい。 それはまさに私が考えていたものです

tsconfig.jsonを介してカスタム変換を指定する方法は夢の実現だと思いました

しかし、それから私は自分の回避策がさらに好きだと気づきました

これが私の考え方です：

• プラグ可能な構成可能なコードジェネレーターが必要でした
• typescriptにはそのような便利なものはありません
• 一方、tslint（2019年末までに減価償却されます）は、コードをプラグインして自由に構成する方法を備えた、typescriptへの適切なプラグインプラットフォームであることを私は知っています
• 必要なものがすべて揃っていることがわかります。
  
  
  
  • プラグ可能で構成可能
  
  
  • 必要なすべてのUI
  
  
  • タイプスクリプトのAPIを教えてくれます
  
  
  • 少し余分なものがあります
  
  

すべてを考えると、typescript言語サービスを使用する何かを書いている自分を見ることができません。理由は次のとおりです。

• 私のラップトップはその数のtypescript言語サービスしか保持できず、そのうちのいくつかはすでに次のとおりです。
  
  
  
  • vscodeの1つ
  
  
  • tslintの1つ
  
  

その上にもう1つ追加したくない

コードトランスフォーマーを接続するためのより良い方法があればいいのにと思いますが、私たちが持っているものはあります

これがマクロのやり方です：＃4892

• 私のラップトップはその数のtypescript言語サービスしか保持できず、そのうちのいくつかはすでに次のとおりです。

  • vscodeの1つ
  • tslintによるもの

@ zpdDG4gta8XKpMCdすべてが同じ言語サービスを使用する必要があると思います。 したがって、単一の言語サービスがあり、プラグインと一緒にtslintプラグインがそれをプロキシします。

ところで、ここでやろうとしていることは、ここでやっていることなので、プレーンランゲージサービスプラグインで間違いなく可能になるはずです。

とにかく、ここでトピックについて話し合いを続け、エディターコードの変更や言語サービスではなくtscを使用したビルドの一部としてカスタムトランスフォーマーについてのみ話し合いましょう。 ほとんどの人は、プロジェクト全体で変換を行うためのソリューションを探していますが、エディター内でそれを行うことは実行可能なソリューションではありません（特に、その時点で変換を行うと、それらを使用する目的が損なわれるため）。 理想的には、ここで実装する必要があるのは、editor / tsserverまたは言語サービスとは何の関係もないはずです。

貴重なご意見ありがとうございます、検討させていただきます

tscを使用したビルドの一部として、カスタムトランスフォーマーについてのみ会話を続けることに同意しません。

• 書かれている元のリクエストは、どのフォームが配信されるかを特定するものではなく、必要がないと述べているだけです。
  > 1つのトランスフォーマーを追加するためだけに、tscコマンドライン全体を複製します
• 2年以上にわたって、この議論は、解決策があり、機能し、使いやすいという条件で、変圧器の実装方法についてあまり気にしていないように見える多くの人々からかなりの注目を集めています。
• また、tslintチームは、プラグインのインフラストラクチャを構築するのに良い仕事をしました。それを使用しないのは、事実上、typescript以外でtypescriptを処理する唯一の公式に認められたプラットフォームであるという条件で、労力の無駄です。
• また、トランスフォーマーがその言語への道を見つけたとしても、すぐには起こらないだろうということには誰もが同意しますが、ここの人々（私を含む）は昨日のようにそれらを必要としていました
• 最後に、より良い選択肢はそれほど多くないので、少なくとも私たちが持っているものを考慮しないのはなぜですか？

私の提案は回避策として明確にラベル付けされています（設計チームが適切な解決策についてより深く考えるために時間を取っている間）、それではなぜですか？

他の場所でやるべきだと主張するなら、声を上げてください

しかし、あなたの非常に懸念に対処するために

プロジェクト全体で変革する

tslintは、cliの--fix引数を使用してまさにそれを実行します

@ zpdDG4gta8XKpMCd --fixは、TypeScriptコードを適切に更新します。 この問題は、emit中に変換を行うことに関するものです（したがって、変更は最終的なJavaScriptファイルにのみ反映されます）。 参照されている問題のPR（＃13940）を参照してください。

＃13764が上陸したので、カスタムトランスフォーマーを簡単に作成できます。 ただし、APIを正しく理解している場合は、単一のトランスフォーマーを追加するためだけに、tscコマンドライン全体を複製する必要があります。 これらは、typescriptに応じて、tscコマンドラインツールと同じ機能をサポートしていないため、これは非互換性につながります。

言い換えれば、その問題はCustomTransformersをもたらしました（そのリンクをクリックして、APIで使用されている場所を確認してください）が、それらを使用するには、 tscを何らかの方法で複製するか、ラップする必要があります。 ttypescriptはそうします。 次に、2番目の段落では、既存のビルドツールにうまく統合されるため、これがどのように役立つかについて説明します（カスタムトランスフォーマーを使用するための方法は、さまざまなビルドツールではなくtscによって処理されるため）。

コードの修正に関する懸念や、TypeScriptコード内でTypeScriptコードを生成するためのより簡単な方法が必要な場合は、新しい問題を開く方が生産性が高いと思います。 今日すでに多くのことが可能であると思うので、これらの懸念が正確に何であるかはわかりませんが、あなたが話し合っているのは、コードの修正/アクションを行う方法です。これは私には無関係の主題のようです。

このスレッドで答える主な質問は、ダニエルが話し合ったこと、「トランスフォーマーの前後だけでなく、もっと広いものがあるかもしれない」、そしてビルドのこの部分を作成するためのソリューションがどのようになるかということだと思います。

あなたは漠然としている

私は簡単なことを理解し、感謝する人です

私が扱っている3500以上のファイルプロジェクトの問題です。そのうちの15％は手作業で作成および保守する必要がなく、その上に同様のものが約5％あります。

同時に、私のためにそれを行うことができるAPIがあることを知っていますが、それは非常に中途半端なので、完全に焼き上げるためにそれを扱う時間を正当化することはできません

だから私がここに来たとき、私はこれがそれについて話すのに適切な場所だと思いました、そしてそれは迅速で簡単な解決策があるかもしれないことがわかりました

ここに来た人の中には、もっと細かいことを話し合うのが不運な人もいます

わかりました、素晴らしいです！

いいえ、tslintが主要な問題の1つをどのように解決できるかをもう一度人々に示すために、新しい問題を開くつもりはありません。

設定可能な変換をすぐに使用できると便利です。 コード内の文字列l10nとi18nの問題に取り組んでいます。 tslintのようなツールを抽出用のカスタムルールで活用できますが、 ttypescriptのようなものを使用しない限り、コードを変換するオプションは限られていますが、それは私がアプリであるため問題があります取り組んでいるのは、排出されていない角度のあるアプリです。 ビルドツールのレイヤーの上にレイヤーを追加する必要があります。 開発のペースに伴い、スタック全体が非常に不安定になります。

現在、フレームワークを開発しており、実行時にタイプレベルの情報にアクセスするために現在ttypescriptを使用しています。最終的には、公式コンパイラにpluginsオプションがあると便利です😄

私は今休暇中ですが、来週戻ってきたら見ます

2019年7月21日午後5時54分[email protected]
書きました：

@longlhohttps ：//github.com/longlhoあなたはたくさんの素晴らしいastを作成しました
トランスフォーマー、私はあなたの助けが必要です👍
Angularのコピーの前にデコレータのメタデータを変更したいと思います。
私の目標は、このノードを変更することです
Component（{セレクター： '標準' ...}）からコンポーネント（{セレクター： 'カスタム'
...}）
テスト用にgithubリポジトリを作成しました
https://github.com/gioboa/ng-ts-transformer 。 可能だと思いますが
ドキュメントなしで私はいくつかの助けが必要です。 🙏ありがとう。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/TypeScript/issues/14419?email_source=notifications&email_token=AABQM335QEEDNVT4NUICJQDQASBDXA5CNFSM4DCFER5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOOR
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABQM33S5IYXB5HOZTRVVX3QASBDXANCNFSM4DCFER5A
。

プロキシを使用せずにインターフェイスから実際のモックを作成するためのライブラリの作成に貢献しました。 今のところttypescriptを使用することをお勧めしますが、typescriptと統合する方法があると便利です

この機能が実現するのを本当に楽しみにしています。 Typescriptとそれがもたらす可能性のある最大の革新のいくつかの間に立っているのはこれだけだと私は確信しています。

Typescriptはフロントエンド開発に多大な貢献をしていますが、さらなる革新にもブレーキをかけています…
セマンティクスを壊さないでください。 プラグインATMはセマンティクスを破ることができません。 プラグインは一切許可されていません：man_shrugging：なぜですか？
本当に良いプラグインがありますが。 すべてのプラグインは、（キー）単語のトークン化とASTインステーションを尊重する必要があります）…、内部で何かを行うのは本当に難しい方法です。
それほど難しいことではありません。 簡単なことではありませんが、babelプロジェクトはそれが可能であることを示しています。
実際、babelが新しいセマンティクスや構文フレーズを導入することはほとんど簡単です。

私はtypescriptからセマンティクスを許可することを期待していません。 （もちろん、構文の変更は期待していません！）
私が望むのは、（タイプのみの場合もある）preevalのように、場合によってはシフトすることです。
routeやmessageなどのtaked関数がある場合と同様に、コンパイラーは事前評価を行い、（フェーズ1で）正確性をチェックできます。

あなたが私の前の段落を読んでいるなら、奇妙です。 tsxとすべてのReactの良さは何ですか？

React、フロー、タイプスクリプトはまったくなく、ほとんど一目ではありません。

お願いします。 私は注意深い見方をよく理解しています。 しかし、IE5.5 +から学ぶと; ブロッキングは前進する方法ではありません。

何か改善が必要な場合でも、それはレイアウトエンジンです。 D.クヌースは50年前にすべての不足している部品を設計したゲニーでした。 なぜ今日これを持っていないのですか？ :-)
JSの悪でCSSをやめるように人々に言ってください。

お願いします。 セマンティクスインテリジェンスのためのオープンTS ; 静的な文字列入力を持つ関数のように、残りの型のヒントを提供します。 実際のconst入力文字列を分析します…
ちょっとした例：

• GraphQL呼び出しのリターンシェイプ
• 国際入力形状
• …もっと_
  お願いします。 セマンティクスの変更は必要ありません。 すべてが希望どおりに機能します。 ビルド時にさらに何かがチェックされる場合があります。 それはすべての人々です！ ：ウサギ：

バンプ

最適化のためにTS変換を記述して実験していcore-js import- @babel/preset-envや@babel/runtimeなどのターゲット環境の自動ポリフィルですが、 babelはありません。 それはTS開発者の大部分を真剣に助けることができます。 ただし、 ttypescriptなどの追加ツールを使用せずに、ボックスからのカスタム変換をサポートしないと、これらの変換を使用できる可能性が大幅に制限されるため、意味があるかどうかはわかりません。

私はそのようなアイデアを実験してきました-https：//github.com/webschik/typescript-polyfills-generator。
Transformers APIは、開発チェーンからbabelを削除する可能性を開くと思います。 多くの開発者は両方を使いたくないと思いますが、それでも@babel/preset-envなどのプラグインが必要です。

この制限のため、現在、独自のカスタムコンパイラスクリプトを（TypeScriptコンパイラAPIを使用して）ロールしています。 ttypescriptについて簡単に説明しましたが、バニラのTypeScriptコンパイラからTypeScriptコンパイラの拡張機能に移行する意欲はありません。

カスタムトランスフォーマーがtsconfig.jsonでサポートされていれば素晴らしいでしょう。 tsconfigを解析し、トランスフォーマーを宣言してからコンパイラーを実行するだけのスクリプトを作成するのは面倒です。 または、さらに悪いことに、カスタムスクリプトで、ファイルの監視など、コンパイラの基本的な機能を実際に再実装しようとします。

他の人々はこの感情を繰り返していますが、カスタムトランスフォーマーをコンパイラーに簡単に統合できるようにすると、TypeScript開発チームの負荷が大幅に軽減され、コミュニティからのこの言語による革新とさらなる前進の勢いが可能になります。

非常に成功したプラグインエコシステムの例は、ServerlessFrameworkのプラグインコミュニティです。 開発チームは機能開発の需要に追いつくことができず、プラグインは、PRを開いたり、コア製品に機能を追加したりする必要なしに、新しい（おそらく実験的な）機能の統合を可能にする優れた方法を可能にします。より広いユーザーベースに価値を提供しません。

私はライブラリを構築していて、その中に私にとってうまく機能し、依存しているデコレータがあります。 少し前に、デコレータによってライブラリがツリーを揺るがすことができないことに気づきました。 それを調べた後、トランスフォーマーは、コンパイル時にこれらのデコレーターをツリーシェイク可能なコードに変換するのに役立つ可能性があるという結論に達しました。 パイプラインでそれらを定義できないのは残念です。 私はあなたがすぐにこの問題に到達することを願っています、それが非常に役立つであろうユースケースに私の2セントを落としたかっただけです。

TypeScriptがラッパープログラムや複雑な命令なしでカスタムトランスフォーマーをサポートするようにするために、 ts-patch （ npm github ）というツールを作成しました。

ts-patchを（グローバルまたはローカルに）インストールし、 ts-patch installを実行してtypescriptにパッチを適用するだけです。 typescriptインストールディレクトリを指定したり、永続性を有効にしたりすることもできます。これにより、TSが更新または再インストールされた場合にパッチが維持されます。 （詳細： ts-patch /? ）

パッチロジックは主にttypescriptに基づいています。 （cevekの素晴らしい仕事に感謝します！）npmパッケージのインストールプロセスに簡単に追加できるように書かれています。 パッチを解除するのも簡単です。

明確にするために、これはtypescript自体の関連ファイルに直接パッチを適用し、ラッパーではありません。 依存関係のインストール後にパッチを実行するだけで、typescriptはトランスフォーマーに対応します。

これが何人かの人々に役立つことを願っています！

TypeScriptがラッパープログラムや複雑な命令なしでカスタムトランスフォーマーをサポートするようにするために、 ts-patch （ npm github ）というツールを作成しました。

ts-patchを（グローバルまたはローカルに）インストールし、 ts-patch installを実行してtypescriptにパッチを適用するだけです。 typescriptインストールディレクトリを指定したり、永続性を有効にしたりすることもできます。これにより、TSが更新または再インストールされた場合にパッチが維持されます。 （詳細： ts-patch /? ）

パッチロジックは主にttypescriptに基づいています。 （cevekの素晴らしい仕事に感謝します！）npmパッケージのインストールプロセスに簡単に追加できるように書かれています。 パッチを解除するのも簡単です。

明確にするために、これはtypescript自体の関連ファイルに直接パッチを適用し、ラッパーではありません。 依存関係のインストール後にパッチを実行するだけで、typescriptはトランスフォーマーに対応します。

これが何人かの人々に役立つことを願っています！

これは、適切なサポートを追加/議論するためのPRとして提起できますか？ :)

おい。 価値のあるものとして、カスタムトランスを非常に簡単に追加できるfuse-boxと呼ばれるバンドラーがあります。 その4.0バージョンはまもなく登場します...それでそれは中間の場所にあります。 しかし、全体的に、私はバンドラーが本当に好きです。 多分それはあなたにも役立つことができます。

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

これは、適切なサポートを追加/議論するためのPRとして提起できますか？ :)

TSチームは、これをネイティブ機能として提供したくないと表明しました。 彼らの決定の理由は理にかなっています！

幸いなことに、TSはオープンソースであり、すでにモジュール方式でコンパイルされているため、ts-patchは、組み込みの場合と非常によく似た動作をします。したがって、バグのあるリバースエンジニアリングされたバイトコードパッチとは異なります。

サポートによって、それが維持されることを心配している場合、私はそれを最新の状態に保ち、TSの将来のすべてのバージョンで機能することを計画しています！ 私の商用インフラストラクチャの多くはすでにそれに依存しています。

ちなみに、エントリポイントの異なる複数のプラグインを1つのパッケージにパッケージ化できる新しいバージョンと、それを改善して使いやすくするためのその他の最適化を間もなくリリースする予定です。

プラグインを作成した後、tsチームが躊躇している理由を理解できます。現在のトランスフォーマーはコンパイル後のステップです。 何か複雑なことをして、元々バインドされていなかった新しいコンテンツを追加し始めると、厄介な問題が発生します。 現状では、 ts-node --compiler ttypescript foo.tsは完全に正常に機能します。 tsチームは、さまざまなコンパイルステップでトランスフォーマープラグインを処理するか、再バインドステップを許可したいと思います。

変流器はコンパイル後のステップです。 何か複雑なことをして、元々バインドされていなかった新しいコンテンツを追加し始めると、厄介な問題が発生します。

トランスフォーマーは、TSCコンパイルの前または後に実行できます。 あなたが言及しているのは、ノードを変更した後、チェッカーが更新されないということのように聞こえます。 これは実際には回避できますが、機能はそのために構築されていません。 ts.transform（）を呼び出すと、操作するための完全なProgramインスタンスが作成されないため、チェッカーを操作する場合は、作成する必要があります。 compilerHostを使用すると、ASTを変更した後、変更したファイルでリロードできます。

まだ詳しくは説明していませんが、「監視」機能を使用して、毎回プログラムインスタンス全体を再構築する必要がないようにすることもできるようです。 簡単に言えば、より完全なプラグインシステムを使用することは実際にはそれほど難しいことではありませんが、トランスフォームは提供されたコンテキストでのサポートを欠いています。

@nonara ttypescriptとts-loader`で変換を使用しましたが、どちらも完全なプログラムエントリポイントを持っています。 私の問題は、新しいインポートステートメントを追加すると、欠落している「何か」とそれらの新しいステートメントが最終的な出力出力から削除されることです。 @weswighamは、変換がバインド後のステップであるため、そのように言っています。 解決策は、ファイル用にまったく新しいプログラムを作成することですが、ts-loaderなどを処理する場合（特に、変換専用モードで、webpack / bundlerファイルを完全に非表示にする場合）は頭痛の種のように見えます-結局、インポートを削除して、必要なコードをインライン化しただけです。

@MeirionHughesああ、わかりました。 その場合、はい、あなたはプログラムインスタンスを持っています。 ttypescriptは、createProgramをフックして、結果のprogramのemitメソッドにパッチを適用してトランスフォーマーを含めることで機能します。

• ts.emitFilesは、プロセス中にts.transformNodes $を呼び出します。
• ts.transformNodesは、Programインスタンスの有無にかかわらず呼び出すことができます。 ts.transform()を直接呼び出すと、それがなくても実行できます。

私が正しく理解していれば、タイプとシンボルがすでにウォークされており、AST変換後に更新されないという事実にも、問題が関係しているように思われます。

皆さん、私がTransformer Handbookを作成して、変圧器に関するすべての情報を同じ場所に配置し、簡単に始められるようにしています。

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

あなたが少し時間を割くことができればそれにいくつかの目を愛したいと思います👍

@madou私はTSトランスフォーマーに関するバンチャ投稿も書きましたhttps://levelup.gitconnected.com/writing-typescript-custom-ast-transformer-part-1-7585d6916819

これの状況はどうですか？

タイプスクリプトが大好きですが、静的タイプとランタイムJSの間で相互運用を開始すると、特に不格好に感じます。 これを改善するためにコミュニティで作成されたプラグインは多数あります。たとえば、 https ：//github.com/dsherret/ts-nameof、https： //github.com/kimamula/ts-transformer-keys-ただし、ファーストクラスのプラグインはサポートされていません。それらをプロジェクトに含めることは、リスクの高い技術的決定のように感じます。 プラグインをネイティブに有効にすると、コミュニティは、コアライブラリにプラグインを含める必要が生じる前に、将来のタイプスクリプト機能の可能性を試すことができます。

TypeScriptチームは彼らの議論を再考すべきだと思います。 プラグインエコシステムは、言語を前進させ、実験を可能にする（そして奨励する）実証済みの方法です（Haskellとそのプラグインを参照）。

それらの実験のいくつかはワイルドでクレイジーであり、いくつかは最終的に安定して一般的になるでしょう。 ユーザースペースに言語機能を実装する機能を提供することは常に良いことです。

一般的に、TypeScriptチームの立場は不必要に厳格に見えます。

言語を変更しないが、デバッグを容易にするための追加情報を提供する変換もあります。

たとえば、 babel-plugin-transform-react-jsx-sourceは、デフォルトの反応トランスパイルプリセット（ @ babel / prefix-react ）の一部です。
変身します

<sometag />

の中へ

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

この情報により、 reactは、開発中により良いエラースタックトレースを提供できます。

タイプスクリプトの場合、オープンソースの変換がありますが、同じことを実現する標準的な方法はありません： https ：//github.com/dropbox/ts-transform-react-jsx-source

@mhegazyが、TSチームがtsconfigの一部として「プラグイン」を含める予定がないことを2回述べたことを理解しています。 この背後にある理由は何ですか？

あなたはPRを受け入れますか？ ttypescriptがtsconfigを介してトランスフォーマーを処理する方法は非常に優れています。

ユースケース：

1）スキーマへのインターフェースタイプを生成して、実行時にチェックできるようにします。
2）文字列をリテラルとして使用してjsonをインポートし、識別された共用体を持つ型に割り当てられたときにtypescriptがバーフしないようにします。
3）css / yamlおよび構文のような他のオブジェクトをインポートする
4）適切なタイプを動的に作成するgraphqlクエリを作成する
5）jsxをhtml文字列にコンパイルして、innerHTMLを挿入できるようにします
5）tsconfigパスに基づいて、絶対インポートを相対インポートに書き換えます。

リストはどんどん増えていきます。 プラグインAPIは素晴らしいです。 着陸していただきありがとうございます。 「tsconfig」の「プラグイン」部分があると、tscは非常に強力になります。 私たちが見逃している大きなものはありますか？

また、多くのパフォーマンスの最適化を行うことができます。 私はhttps://github.com/atlassian-labs/compiled-css-in-jsをtypescriptトランスフォーマーで書いてきました🤙消費者がそれを使用するためにフープを飛び越える必要がなければ、クールでしょう。

Typescriptチームの皆様、この<_ <にかかとをドラッグするのはやめてください。

これの状況はどうですか？

スターテス？

友達はどんなニュース？

タイプスクリプトチームはこのアイデアに反対することを決定しました-柔軟性が必要な場合、またはタイプスクリプトを使用するより良い開発ツールがハックなしのオプションではない場合-代わりにbabelを使用し、タイプチェックにのみタイプスクリプトを使用してください

タイプスクリプトチームはこのアイデアに反対することを決定しました-柔軟性が必要な場合、またはタイプスクリプトを使用するより良い開発ツールがハックなしのオプションではない場合-代わりにbabelを使用し、タイプチェックにのみタイプスクリプトを使用してください

しかし、タイプチェックのためにいくつかのハックが必要な場合はどうなりますか？ 私はいくつかの魔法を作る小さなトランスを書きます：

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

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

関数checkが特定のタイプガード関数に変換されました！ Babelでどうやって作ることができますか？ 現在、ttypescriptを使用する必要があります...

タイプスクリプトチームはこのアイデアに反対することを決定しました-柔軟性が必要な場合、またはタイプスクリプトを使用するより良い開発ツールがハックなしのオプションではない場合-代わりにbabelを使用し、タイプチェックにのみタイプスクリプトを使用してください

実際、これが将来サポートされるようになるという話がいくつかあります。 そうは言っても、それは本当にすでにサポートされています。 TypeScriptコンパイラAPIはトランスフォーマーをサポートしており、ほんの数行のコードでトランスフォーマーを使用するカスタムコンパイラーを作成するのは_本当に_簡単です。

ただし、簡単にするために、 ttypescriptまたはts-patchを使用できます。

これらのライブラリは、トランスフォーマー機能を追加するためにコンパイラーを拡張していないという意味で、実際には「ハック」ではありません。 代わりに、コンパイラAPIの既存の機能をtscに公開するだけで、tsconfigを介して使用できるようになります。

@ ilya-buligin私があなたのユースケースを正しく理解していれば、周囲定数を宣言できます

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

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

Typescriptは、 check型定義に基づいてコードをコンパイルし、Babelを使用して生成されたコードに置き換えます。

@ just-boris Babelでジェネリック型<T>にアクセスするにはどうすればよいですか？

このスレッドはかなり反復的で話題から外れています。 @RyanCavanaughおそらく、この件名に関する更新があるまで、このスレッドをロックする必要があります。