ts proto

ts-proto

ts-proto .protoファイルを強く慣用型タイプスクリプトファイルに変換します！

TS-PROTO 2.Xリリースノート

TS-PROTOの2.xリリースは、低レベルのプロトブフシリアル化を移行しました。これは、そのencodeおよびdecodeメソッドの使用を由緒あるが、老化して停滞したprotobufjsパッケージを@bufbuild/protobufに移行しました。

encodeとdecodeメソッドのみを使用した場合、これは主に非壊れた変更である必要があります。

ただし、古いprotobufjs WriterまたはReaderクラスを使用したコードを使用した場合、新しい@bufbuild/protobufクラスを使用するためにコードを更新する必要があります。

import { BinaryReader, BinaryWriter } from "@bufbuild/protobuf/wire";

@bufbuild/protobufに移行することがブロッカーである場合、 ts-protoバージョンを1.xに固定できます。

免責事項と謝罪：私はTS-Proto 2.xをアルファリリースとしてリリースするつもりでしたが、セマンティックリリースの構成を正しく取得していなかったため、TS-PROTO 2.Xは適切なアルファなしの主要なリリースとして公開されました/ベータサイクル。

リリースがまだ新鮮である間に出会った問題についてレポート（またはより良いPRS！）を提出できれば、それは大歓迎です。

移行に関する他の人のためのヒントやコツも感謝します！

目次

• ts-proto

• 目次

• 概要

• クイックスタート

• buf

• ESM

• 目標

• 非ゴール

• 例の例

• ハイライト

• 自動バッチ / n+1予防

• 使用法

• サポートされているオプション

• NestJSサポート

• ウォッチモード

• 基本的なGRPC実装

• スポンサー

• 発達

• 仮定

• トト

• 1つの取り扱い

• デフォルト値と未解決のフィールド

• よく知られているタイプ

• ラッパータイプ

• JSONタイプ（構造タイプ）

• タイムスタンプ

• 数字タイプ

• オプションの値の現在のステータス

概要

TS-Protoは、Protobufスキーマからタイプスクリプトタイプを生成します。

つまり、 person.proto schemaのようなものを与えられました：

メッセージ担当者{文字列名= 1;
}

TS-PROTOは、次のようなperson.tsファイルを生成します。

インターフェイスパーソン{
  名前：string} const person = {
  エンコード（人）：ライター{...}
  デコード（リーダー）：人{...}
  トジソン（人）：不明{...}
  fromjson（data）：person {...}}

また、サービスについても知っており、それらのタイプも生成します。

インターフェイスpingserviceをエクスポート{
  ping（リクエスト：pingrequest）：約束<pingResponse>;}

また、 PingServiceのクライアント実装も生成されます。現在、TWIRP、GRPC-WEB、GRPC-JS、およびNESTJSがサポートされています。

クイックスタート

• npm install ts-proto

• protoc --plugin=./node_modules/.bin/protoc-gen-ts_proto --ts_proto_out=. ./simple.proto

• （出力パラメーター名、 ts_proto_outは、プラグインの名前の接尾辞、すなわち--plugin=./node_modules/.bin/protoc-gen-ts_protoパラメーターに_out prefixになります。 Per protocのCLIコンベンション。）

• Windowsでは、 protoc --plugin=protoc-gen-ts_proto=".node_modules.binprotoc-gen-ts_proto.cmd" --ts_proto_out=. ./simple.protoを参照）

• 最新のprotoc使用していることを確認してください（プラットフォームのインストール手順を参照してください。 protoc 3.0.0 _optフラグをサポートしていません

これにより、指定された*.protoタイプの*.tsソースファイルが生成されます。

これらのソースファイルをNPMパッケージにパッケージ化してクライアントに配布する場合は、通常どおりtsc実行して.js / .d.tsファイルを生成し、通常のNPMパッケージとして出力を展開します。

buf

BUFを使用している場合は、 buf.gen.yamlファイル（docs）にstrategy: allします。

バージョン：V1Plugins：
   - 名前：tsout：../gen/tsstrategy：allpath：../node_modules/ts-proto/protoc-gen-ts_proto

buf push無関係な.protoファイルを読むのを防ぐために、 buf.yamlのように構成します：

ビルド：除外：[node_modules]

また、BUFレジストリに公開されている公式プラグインを使用することもできます。

バージョン：V1Plugins：
   - プラグイン：buf.build/community/stephenh-ts-protoout：../gen/tsopt：
      -OUTPUTSERVICES = ... -UESEXACTTYPES = ...

ESM

esModuleInteropを使用して最新のTSセットアップを使用している場合、またはESM環境で実行している場合は、次のts_proto_optを渡す必要があります。

• esModuleInterop=true tsconfig.jsonでesModuleInteropを使用している場合、and

• importSuffix=.js ESM環境で生成されたTS-PROTOコードを実行する場合

目標

ts-proto生成するコードに関しては、一般的な目標は次のとおりです。

• 慣用型タイプスクリプト/ES6タイプ

• ts-proto 、組み込みのGoogle/Java-Esque JS protocコードまたは「 .d.tsファイルを作成します*.jsコメント」というprotobufjsのいずれかからのクリーンな休憩です。

• （技術的には、 protobufjs/minimal Packageが実際にバイトを読み取り/書き込むために使用されます。）

• TypeScript-First出力

• クラス上のインターフェイス

• 可能な限り、タイプは単なるインターフェイスであるため、通常のハッシュ/データ構造のようにメッセージを使用できます。

• codegen *.proto .proto *.tsワークフローのみをサポートしています。

非ゴール

TS-Protoは、すぐに使用できるRPCフレームワークではないことに注意してください。代わりに、それはより多くの構成オプションで目撃されているスイスのナイフのようなものであり、その上にあなたが望むRPCフレームワークを正確に構築できます（つまり、あなたの会社のProtoBufエコシステムと統合するのが最適です。良くも悪くも、Protobuf RPCは依然としてやや断片化された生態系です）。

TS-Protoの上に構築されたすぐに使用できるRPCフレームワークが必要な場合は、いくつかの例があります。

• nice-grpc

• starpc

（潜在的な貢献者については、他のフレームワーク/ミニフレームワーク、さらにはブログ投稿/チュートリアルを開発した場合、 ts-protoの使用については、喜んでリンクさせてください。）

また、 google.api.httpベースのGoogleクラウドAPIのクライアントをサポートしていません。PRを送信する場合は＃948を参照してください。

例の例

生成されたタイプは「データだけ」です。

インターフェイスをエクスポートsimple {
  名前：文字列;
  年齢：数;
  createdat：日付|未定義;
  子供：子供|未定義;
  状態：StateEnum;
  孫：子供[];
  コイン：number [];}

encode / decodeファクトリーメソッド：

 const simple = {{{{
  create（baseObject？：deeppartial <simple>）：simple {...}、

  エンコード（メッセージ：simple、writer：writer = writer.create（））：writer {...}、

  デコード（読者：読者、長さ？：番号）：simple {...}、

  fromjson（オブジェクト：任意）：simple {...}、

  frompartial（object：deeppartial <simple>）：simple {...}、

  Tojson（メッセージ：シンプル）：不明{...}、};

これにより、次のような慣用的なTS/JSの使用が可能になります。

 const bytes = simple.encode（{name：...、age：...、...}）。finish（）; const simple = simple.decode（reader.create（bytes））; const {name、age } = simple;

クラスを作成せず、適切なゲッター/セッターを呼び出すことなく、他のレイヤーに出会うときに統合を劇的に容易にすることができます。

ハイライト

• 「オプションの種類をバックバックしてください」という貧しい男の試み

  標準プロトブフラッパータイプ、すなわちgoogle.protobuf.StringValueは、オプションの値としてマッピングされていますstring | undefined 。つまり、プリミティブにとっては、Protobufタイプのシステムにはオプションのタイプがあるふりをすることができます。

  （更新：TS-Protoは、Proto3 optionalキーワードもサポートしています。）

• タイムスタンプはDateとしてマッピングされます

  （ useDateパラメーターで構成できます。）

• fromJSON / toJSON protobufjsとは異なり、Proto3 Canonical JSONエンコード形式（タイムスタンプはISO文字列です）を使用します。

• ObjectIdsは、 mongodb.ObjectIdとしてマッピングできます

  （ useMongoObjectIdパラメーターで構成可能。）

自動バッチ / n+1予防

（注：これは現在、TWIRPクライアントによってのみサポートされています。）

TS-Protoのクライアントを使用して、SQLアプリケーションのN+1問題と同様に、マイクロサービスをバックエンドでコールする場合、マイクロサービスクライアントが（個々のリクエストを提供するとき）、複数の個別のRPC呼び出しを誤ってトリガーするのは簡単です。 「Get Book 1」、「Get Book 2」、「Get Book 3」、それは本当に単一の「Get Books [1、2、3]」にバッチされるはずです（バックエンドがバッチ指向のRPCメソッドをサポートすると仮定します）。

TS-Protoはこれを支援し、本質的に個々の「Get Book」コールをバッチ付き「Get Books」コールに自動バッチします。

TS-PROTOがこれを行うには、次のバッチ条約でサービスのRPCメソッドを実装する必要があります。

• Batch<OperationName>

• Batch<OperationName>入力タイプには、単一の繰り返しフィールドがあります（つまり、 repeated string ids = 1 ）

• Batch<OperationName>出力タイプには次のいずれかがあります。

• 出力順序が入力ids注文と同じである単一の繰り返しフィールド（つまり、 repeated Foo foos = 1

• 出力への入力のマップ（IE map<string, Entity> entities = 1; ）

TS-PROTOがこのパターンのメソッドを認識すると、クライアント、つまりクライアントの<OperationName>の「非バッチ」バージョン、つまりclient.Get<OperationName>自動的に作成します。

これにより、クライアントコードは、個々のGet<OperationName>コール（クライアントのビジネスロジックを実装するときに一般的に望ましい/簡単です）を作成できるという幻想を提供しますが、TS-Protoが提供する実際の実装は、 Batch<OperationName>を作成することになります。バックエンドサービスへの呼び出し。

また、すべてのgetDataLoadersメソッドにGo-Style ctxパラメーターを提供するuseContext=true Build-Timeパラメーターを有効にする必要があります。検出/フラッシング動作。

例/詳細については、 batching.protoファイルと関連するテストを参照してください。

しかし、最終的な効果は、TS-ProtoがクライアントコールにSQL- / ORMスタイルN+1予防を提供できることです。 。

使用法

ts-protoはprotocプラグインであるため、プロジェクトで直接、またはモノレポスキーマパイプライン、つまりイボッタのようなものであるか、つまり）によって実行されます。

• package.jsonにts-proto追加します

• npm install実行してダウンロードします

• 次のようなpluginパラメーターを使用してprotoc呼び出します。

 protoc -plugin = node_modules/ts-proto/protoc-gen-ts_proto ./batching.proto -i。

ts-proto protobuf-gradle-pluginを使用してGradleで呼び出すこともできます。

 protobuf {
    プラグイン{// `ts`は、未使用のプラグイン名、例えば` tsproto`ts {
            path = 'path/to/plugin'}
    } //このセクションは、プラグインオプションを提供する場合にのみ必要です。
        all（）。各{task-> task.plugins {//プラグインIDと宣言されたabovetsを一致させる必要があります{
                    オプション 'foo = bar'}
            }
        }
    }
}

生成されたコードは、Gradleビルドディレクトリに配置されます。

サポートされているオプション

• --ts_proto_opt=globalThisPolyfill=trueで、ts-protoにはglobalthisのポリフィルが含まれます。

  デフォルトはfalseです。つまり、 globalThisが利用可能であると想定しています。

• --ts_proto_opt=context=trueで、サービスにはゴースタイルのctxパラメーターがあり、トレース/ロギング/などに役立ちます。パフォーマンスの理由により、Nodeのasync_hooks APIを使用していない場合。

• --ts_proto_opt=forceLong=longでは、64ビットのすべての数値がLongインスタンスとして解析されます（長いライブラリを使用）。

  --ts_proto_opt=forceLong=stringで、すべての64ビット番号が文字列として出力されます。

  --ts_proto_opt=forceLong=bigintで、すべての64ビット番号がBigIntとして出力されます。このオプションは、 longライブラリを使用してprotobuf.js内で内部的にエンコード/デコードしますが、TS-Protoで生成されたコードのBigIntに変換されます。

  デフォルトの動作はforceLong=numberです。これは内部的にlongライブラリを使用してワイヤー上の値をエンコード/デコードします（したがって、 util.Long = Long line in your output）が、 long値をnumberに変換しますあなたのために自動的に。この変換を行うと、64ビット値がnumberとして正しく保存できるよりも大きい場合、ランタイムエラーがスローされることに注意してください。

• --ts_proto_opt=useJsTypeOverrideで、フィールドで指定されたfieldoption.jstypeとして64ビット番号が出力されます。これは、提供されたforceLongオプションよりも優先されます。

• --ts_proto_opt=esModuleInterop=true変更出力がesModuleInteropに準拠します。

  具体的には、 Long輸入品はimport Long from 'long' import * as Long from 'long'輸入品として生成されます。

• --ts_proto_opt=env=nodeまたはbrowser 、またはbothで、ts-protoは出力で環境固有の仮定を行います。これはbothになり、環境固有の仮定はありません。

  nodeを使用すると、 Uint8ArrayからBufferまでのbytesの種類が変更され、一般的にBufferを使用するノードエコシステムとの統合が容易になります。

  現在、 browser 「 nodeではない」以外の特定の動作はありません。それはおそらくすぐに/ある時点ででしょう。

• --ts_proto_opt=useOptionals=messages （メッセージフィールド用）または - ts_proto_opt = useoptionals field: Message | undefined --ts_proto_opt=useOptionals=all （メッセージおよびスカラーフィールド用）、フィールドはオプションキーとして宣言されますfield?: Message field: Message | undefined 。

  ts-protoはuseOptionals=noneにデフォルトです。

  タイプミスの予防のために、オプションのフィールドにより、余分なフィールドがメッセージに簡単に滑り込むことができます（正確なタイプを取得するまで）、つまり：

  インターフェイスSomeMessage {
    FirstName：文字列;
    lastname：string;} // typoconst data = {firstName： "a"、lasttypo： "b"}; // useoptionals = noneで宣言された、これは正しくコンパイルできません。 「lastname」がオプションであった場合、それはメッセージを構成しません：somemessage = {... data};

  一貫したAPIの場合、 SomeMessage.lastNameがオプションのlastName? 、次に、読者は2つの空の条件をチェックする必要があります。a） lastName undefined （b/cはメモリ内で作成されて解除されたまま）、またはb） lastNameの空の文字列（b/cはワイヤーからのSomeMessage読みます。 proto3仕様、初期化されたlastNameから空の文字列）？

  適切な初期化を確保するために、後でSomeMessage.middleInitialが追加された場合、それはオプションの中middleInitial? 、生産コードに多くのコールサイトがあるかもしれません。これは、有効なSomeMessageを作成するためにmiddleInitial通過するはずですが、そうではありません。

  したがって、タイプミスプレベーション、読者の矛盾、適切な初期化の間に、TS-PROTOは、 useOptionals=none 「最も安全な」オプションとして使用することをお勧めします。

  とはいえ、このアプローチでは、作家/クリエイターがすべてのフィールドを設定する必要があります（ fromPartial and createこれに対処するためのものですが）。したがって、オプションのキーを使用する場合は、 useOptionals=messagesまたはuseOptionals=allを設定できます。

  （ useOptionalに関する議論については、この問題とこの問題を参照してください。）

1. メッセージを初期化するときにタイプミスを防ぎます

2. 読者に最も一貫したAPIを提供します

3. すべてのフィールドで生産メッセージが適切に初期化されるようにします。

• --ts_proto_opt=exportCommonSymbols=false 、 DeepPartialやprotobufPackageなどのユーティリティタイプはexportされません。

  これにより、生成された出力、つまり./fooおよびimport * from ./bar import * from ./fooのバレルインポートの作成が可能になります。

  複数の*.protoファイルで同じメッセージ名がある場合でも、インポート競合が表示されることに注意してください。

• --ts_proto_opt=oneof=unionsでは、 oneofフィールドがADTSとして生成されます。

  「1つの処理」セクションを参照してください。

• with with --ts_proto_opt=unrecognizedEnumName=<NAME> enumsには、 unrecognizedEnumValueオプションの値を持つkey <NAME>が含まれます。

  デフォルトは認識されてUNRECOGNIZED 。

• with --ts_proto_opt=unrecognizedEnumValue=<NUMBER> enumsには、 <NUMBER>の値を持つunrecognizedEnumNameオプションによって提供されるキーが含まれます。

  デフォルトは-1です。

• --ts_proto_opt=unrecognizedEnum=false enumsには、認識さunrecognizedEnumNameおよび承認unrecognizedEnumValue eNumの価値が含まれていないことは含まれていません。

• --ts_proto_opt=removeEnumPrefix=true生成されたenumsは、メンバーから列挙名を削除します。

  FooBar.FOO_BAR_BAZ = "FOO_BAR_BAZ" FooBar.BAZ = "FOO_BAR_BAZ"を生成します "

• --ts_proto_opt=lowerCaseServiceMethods=true service.findFoo service.FindFoo

• --ts_proto_opt=snakeToCamel=falseで、フィールドはメッセージキーとtoJSON / fromJSONメソッドの両方でヘビのケースを維持します。

  snakeToCamel 、文字列の_ -delimitedリストとして設定することもできます（コンマkeysフラグが区切られたjsonに予約されています）、すなわち--ts_proto_opt=snakeToCamel=keys_json 。キャメルケース。

  空の文字列、すなわちsnakeToCamel=は、メッセージキーとJSONキーの両方をスネークケースとして保持します（ snakeToCamel=falseと同じです）。

  json_name属性を使用するには、 json使用する必要があることに注意してください。

  デフォルトの動作はkeys_jsonです。つまり、両方ともキャメルケースがあり、 json_nameが設定されている場合は使用されます。

• --ts_proto_opt=outputEncodeMethods=false 、 Message.encode and Message.decodeメソッドProtoBuf-Encoded/バイナリデータを操作するためのメソッドは出力されません。

  これは、「のみタイプ」が必要な場合に便利です。

• --ts_proto_opt=outputJsonMethods=false 、 Message.fromJSONおよびMessage.toJSON Jsonコードデータを操作するためのメソッドは出力されません。

  これは、「のみタイプ」が必要な場合にも便利です。

• --ts_proto_opt=outputJsonMethods=to-only and --ts_proto_opt=outputJsonMethods=from-onlyから、 Message.toJSONとMessage.fromJSONメソッドの間で1つだけをエクスポートできます。

  これは、TS-Protoを使用して、両方ではなくencodeまたはdecodeためだけに使用する場合に役立ちます。

• --ts_proto_opt=outputPartialMethods=false 、 Message.fromPartial and Message.createメソッドは、部分的に形成されたオブジェクト/オブジェクトリテラルを受け入れるためのメソッドは出力されません。

• --ts_proto_opt=stringEnums=trueで、生成された列挙型はintベースではなく文字列ベースになります。

  これは、「のみタイプ」が必要であり、列挙を文字列としてシリアル化するように構成されたGRPC RESTゲートウェイを使用している場合に役立ちます。

  （ outputEncodeMethods=falseが必要です。）

• --ts_proto_opt=outputClientImpl=falseを使用して、クライアント側（TWIRPではgrpc-webの次のオプションを参照）を実装するクライアントの実装、つまりFooServiceClientImpl使用して出力されません。

• --ts_proto_opt=outputClientImpl=grpc-webで、クライアントの実装、すなわちFooServiceClientImplは、実行時に @expbable-eng/grpc-webライブラリを使用してGRPC-webバックエンドにGRPCメッセージを送信します。

  （これはGRPC-WEBランタイムのみを使用していることに注意してください。生成されたコードを使用する必要はありません。つまり、TS-Protoの出力はts-protoc-gen出力を置き換えます。）

  @improbable-eng/grpc-web追加し、プロジェクトのpackage.jsonにトランスポートを追加する必要があります。実用的な例については、 integration/grpc-webディレクトリを参照してください。 GRPC-WEB-Devtoolsとの統合については、＃504も参照してください。

• --ts_proto_opt=returnObservable=true Promise<T> Observable<T>

• --ts_proto_opt=addGrpcMetadata=trueで、サービスメソッドの最後の引数は、コールに追加情報を含むGRPC Metadataタイプを受け入れます（つまり、アクセストークン/など）。

  （ nestJs=trueが必要です。）

• --ts_proto_opt=addNestjsRestParameter=trueで、サービスメソッドの最後の引数は、タイプのRESTパラメーターになります。このようにして、通常はnestjsで使用できるカスタムデコレータを使用できます。

  （ nestJs=trueが必要です。）

• --ts_proto_opt=nestJs=trueを使用すると、デフォルトは変更され、nestjs protobuf実装のクライアント側とサーバー側の両方で使用できるNestjsプロトブフレンドリータイプとサービスインターフェイスが生成されます。詳細と実装の例については、nestjs readmeを参照してください。

  具体的には、 outputEncodeMethods 、 outputJsonMethods 、およびoutputClientImplはすべて偽りになります。 lowerCaseServiceMethodsは真であり、 outputServices無視されます。

  addGrpcMetadata 、 addNestjsRestParameter 、およびreturnObservableまだ虚偽であることに注意してください。

• with --ts_proto_opt=useDate=false 、タイプのフィールドgoogle.protobuf.Timestamp生成されたタイプのDateを入力することはマッピングされません。詳細については、タイムスタンプを参照してください。

• --ts_proto_opt=useMongoObjectId=true 、objectIdと呼ばれるタイプのフィールドは、[生成された型のmongodb.ObjectIdと型と呼ばれるフィールドと呼ばれるフィールドに構築されます。これには、プロジェクトがMongoDB NPMパッケージをインストールする必要があります。詳細については、ObjectIDを参照してください。

• --ts_proto_opt=annotateFilesWithVersion=falseで、生成されたファイルには、ファイルの生成に使用されるprotocとts-protoのバージョンは含まれません。このオプションは通常、ファイルが使用されるバージョンをリストするようにtrueに設定されます。

• --ts_proto_opt=outputSchema=trueで、メタタイピングが生成され、後で他のコードジェネレーターで使用できます。

• --ts_proto_opt=outputSchema=no-file-descriptorでは、メタタイピングが生成されますが、生成されたスキーマにファイル記述子を含めません。これは、生成されたスキーマのサイズを最小限に抑えようとしている場合に役立ちます。

• --ts_proto_opt=outputSchema=constで、メタタイピングがas const生成され、すべてのプロパティにタイプセーフアクセスが可能になります。 （TypeScript 4.9以降でのみ動作します。これは、 satisfiesオペレーターも使用するためです）。生成されたスキーマにファイル記述子を含めないようにno-file-descriptorオプション（ outputSchema=const,outputSchema=no-file-descriptor ）と組み合わせることができます。

• --ts_proto_opt=outputTypeAnnotations=trueで、各メッセージには、完全に資格のある名前を含む$typeフィールドが与えられます。 --ts_proto_opt=outputTypeAnnotations=optional interface --ts_proto_opt=outputTypeAnnotations=static-onlyを使用して、 interface宣言から省略します。後者のオプションは、サーバーからの応答のランタイムタイプチェックに$typeフィールドを使用する場合に役立ちます。

• --ts_proto_opt=outputTypeRegistry=trueで、完全に資格のある名前でメッセージタイプを解決するために使用できるタイプレジストリが生成されます。また、各メッセージには、完全に資格のある名前を含む$typeフィールドが与えられます。

• --ts_proto_opt=outputServices=grpc-jsを使用すると、TS-ProtoはGRPC-JS形式でサービス定義とサーバー /クライアントスタブを出力します。

• --ts_proto_opt=outputServices=generic-definitionsでは、TS-PROTOはジェネリック（フレームワークと依存）サービス定義を出力します。これらの定義には、リクエストと応答タイプへのリンクを備えた各メソッドの記述子が含まれています。これにより、実行時にサーバーとクライアントのスタブを生成し、コンパイル時に強力なタイプを生成できます。このアプローチを使用するライブラリの例は、NICE-GRPCです。

• --ts_proto_opt=outputServices=nice-grpc 、ts-protoはnice-grpcのサーバーとクライアントスタブを出力します。これは、一般的な定義と一緒に使用する必要があります。つまり、2つのオプションを指定する必要があります。AutputServices outputServices=nice-grpc,outputServices=generic-definitions 。

• --ts_proto_opt=metadataType=Foo@./some-file 、ts-protoは汎用（フレームワークと存在する）メタデータフィールドを汎用サービス定義に追加します。

• --ts_proto_opt=outputServices=generic-definitions,outputServices=default 、TS-PROTOは、一般的な定義とインターフェイスの両方を出力します。これは、インターフェイスに頼りたい場合に役立ちますが、実行時にはいくつかの反射機能もあります。

• --ts_proto_opt=outputServices=false 、または=noneでは、ts-protoはサービス定義を出力しません。

• --ts_proto_opt=rpcBeforeRequest=true 、ts-protoは、signature： beforeRequest(service: string, message: string, request: <RequestType>)を使用してRPCインターフェイス定義に関数定義を追加します。また、自動的にoutputServices=defaultを設定します。各サービスのメソッドは、リクエストを実行する前にbeforeRequestを呼び出します。

• --ts_proto_opt=rpcAfterResponse=true 、ts-protoは、signature： afterResponse(service: string, message: string, response: <ResponseType>)を使用してRPCインターフェイス定義に関数定義を追加します。また、自動的にoutputServices=defaultを設定します。各サービスのメソッドは、応答を返す前にafterResponse後に呼び出します。

• --ts_proto_opt=rpcErrorHandler=true 、ts-protoは、signerature： handleError(service: string, message: string, error: Error)を使用して、rpcインターフェイス定義に関数定義を追加します。また、自動的にoutputServices=defaultを設定します。

• --ts_proto_opt=useAbortSignal=trueで、生成されたサービスは、RPC呼び出しをキャンセルするためにAbortSignalを受け入れます。

• --ts_proto_opt=useAsyncIterable=true使用すると、生成されたサービスはObservableではなく非AsyncIterableです。

• -ts_proto_opt protoc google/protobuf/* --ts_proto_opt=emitImportedFiles=false protoc --plugin=./node_modules/.bin/protoc-gen-ts_proto my_message.proto google/protobuf/duration.proto

• --ts_proto_opt=fileSuffix=<SUFFIX>で、TS-PROTOは指定された接尾辞を使用して生成されたファイルを発します。 fileSuffix=.pbを使用したhelloworld.protoファイルは、 helloworld.pb.tsとして生成されます。これは、他のプロトックプラグインでの一般的な動作であり、生成されたすべてのファイルをすばやくグローブする方法を提供します。

• --ts_proto_opt=importSuffix=<SUFFIX>で、ts-protoは指定されたサフィックスを使用してファイルインポートを発します。 fileSuffix=.jsを使用したhelloworld.tsのインポートはimport "helloworld.js"を生成します。デフォルトは、ファイル拡張子なしでインポートすることです。 TypeScript 4.7.x以降でサポートされています。

• --ts_proto_opt=enumsAsLiterals=true as const

• --ts_proto_opt=useExactTypes=falseを使用して、生成されたfromPartialとcreateメソッドは正確なタイプを使用しません。

  デフォルトの動作は、 useExactTypes=trueであり、それはfromPartialになり、その引数に正確なタイプを使用createて、タイプスクリプトを不明なプロパティを拒否するようにします。

• --ts_proto_opt=unknownFields=trueで、すべての不明なフィールドは解析され、バッファーの配列として出力されます。

• --ts_proto_opt=onlyTypes=trueでは、型のみが放出され、 longおよびprotobufjs/minimalのインポートが除外されます。

  これはoutputJsonMethods=false,outputEncodeMethods=false,outputClientImpl=false,nestJs=falseの設定と同じです

• --ts_proto_opt=usePrototypeForDefaults=trueで、生成されたコードはObject.createで新しいオブジェクトをラップします。

  これにより、コードはHazzerチェックを行い、デフォルト値が適用されたときに検出できます。これは、Proto3のWireにデフォルト値を置かないという動作により、通常、Proto2メッセージとの相互作用にのみ役立ちます。

  有効にすると、デフォルト値はプロトタイプから継承されるため、コードはobject.keys（）を使用できます。

  示されているように、これはobject.keysにはセットバイデフォルトフィールドが含まれないことを意味します。したがって、メッセージキーを一般的に繰り返すコードがある場合、プロトタイプから継承されたキーを繰り返す必要があります。

• --ts_proto_opt=useJsonName=true 、json_nameプロトファイルで定義されたjson_name 、メッセージフィールド名の代わりに使用されます。

• --ts_proto_opt=useJsonWireFormat=trueで、生成されたコードは、プロトブフメッセージのJSON表現を反映します。

  onlyTypes=trueが必要です。 useDate=string and stringEnums=trueこのオプションは、JSONとしてシリアル化されたMarshalling/Marshalling Protobufメッセージで直接使用できるタイプを生成することです。 Scalar値のデフォルト値を送信するためにGRPCゲートウェイが必要ないため、 useOptionals=all設定することもできます。

• --ts_proto_opt=useNumericEnumForJson=trueで、JSONコンバーター（ toJSON ）は、文字列リテラルではなく、enum値をintとしてエンコードします。

• --ts_proto_opt=initializeFieldsAsUndefined=falseで、すべてのオプションのフィールドイニシャルは生成されたベースインスタンスから省略されます。

• --ts_proto_opt=disableProto2Optionals=trueで、proto2ファイルのすべてのオプションフィールドはオプションに設定されません。このフラグは、主にTS-ProtoのProto2ファイルのレガシー処理を維持するためのものであり、変化を避けるためであり、その結果、前進することを意図していないことに注意してください。

• --ts_proto_opt=disableProto2DefaultValues=trueで、デフォルト値を指定するproto2ファイルのすべてのフィールドは、実際にそのデフォルト値を使用しません。このフラグは、主にTS-ProtoのProto2ファイルのレガシー処理を維持するためのものであり、変化を避けるためであり、その結果、前進することを意図していないことに注意してください。

• --ts_proto_opt=Mgoogle/protobuf/empty.proto=./google3/protobuf/empty ./google/protobuf/empty.tsオーバーライドされた値を反映しています。

• Mfoo/bar.proto=@myorg/some-lib /some-libは、 foo/bar.protoインポートをimport ... from '@myorg/some-lib'にマッピングします。

• Mfoo/bar.proto=./some/local/lib foo/bar.protoインポートをimport ... from './some/local/lib' 。

• Mfoo/bar.proto=some-modules/some-lib foo/bar.proto import ... from 'some-module/some-lib'マッピングします。

• 注：使用が蓄積されるため、 --ts_proto_opt=M... --ts_proto_opt=M... （マッピングごとに1つのts_proto_opt ）の形式で複数の値が予想されます。

• 注：マッピングされたインポートと一致するプロトファイルは生成されません。

• --ts_proto_opt=useMapType=trueで、protobuf map<key_type, value_type>の生成コードは、javascriptマップタイプを使用するMap<key_type, value_type>になります。

  デフォルトの動作はuseMapType=falseです。これにより{[key: key_type]: value_type}のようなkey-valueペアを使用して、protobuf map<key_type, value_typeのコードを生成します。

• --ts_proto_opt=useReadonlyTypes=true readonly

• with --ts_proto_opt=useSnakeTypeName=falseは、タイプからヘビのケーシングを削除します。

  例Protobuf

  メッセージボックス{メッセージ要素{メッセージ画像{enum alignment {left = 1;                      Center = 2;                      右= 3;
                  }
            }
        }
  }

  デフォルトでは、これが有効になっており、 Box_Element_Image_Alignmentの種類を生成します。このオプションを無効にすることにより、生成されるタイプはBoxElementImageAlignmentになります。

• --ts_proto_opt=outputExtensions=trueで、生成されたコードにはproto2拡張子が含まれます

  拡張エンコード/デコードメソッドは、 outputEncodeMethodsオプションに準拠しており、 unknownFields=trueの場合、拡張可能なメッセージに対してsetExtensionおよびgetExtensionメソッドが作成され、 outputEncodeMethods （setextension = encode、getextension = decode）にも準拠します。

• --ts_proto_opt=outputIndex=trueで、indexファイルはprotoパッケージ名空間に基づいて生成されます。

  これにより、共通のシンボルの名前の衝突を避けるために、 exportCommonSymbols無効になります。

• --ts_proto_opt=emitDefaultValues=json-methodsでは、生成されたトジソン法は、jsonフィールドとして0や""などのスカラーを排出します。

• --ts_proto_opt=comments=falseで、コメントはprotoファイルから生成されたコードにコピーされません。

• --ts_proto_opt=bigIntLiteral=falseで、生成されたコードは、bigintリテラルの場合は0nの代わりにBigInt("0")を使用します。 「ES2020」よりも古いものに設定された「ターゲット」コンパイラオプションがタイプスクリプトによってサポートされていません。

• --ts_proto_opt=useNullAsOptional=true 、 undefined値はnullに変換され、 .protoファイルでoptionalラベルを使用すると、フィールドにもundefinedタイプがあります。例えば：

• --ts_proto_opt=typePrefix=MyPrefixでは、生成されたインターフェイス、列挙、および工場には、名前にMyPrefixの接頭辞があります。

• --ts_proto_opt=typeSuffix=MySuffixでは、生成されたインターフェイス、enums、および工場には、名前にMySuffixの接尾辞があります。

メッセージprofileinfo {int32 id = 1; string bio = 2; string phone = 3;
}メッセージ部門{int32 id = 1; string name = 2;
} message user {int32 id = 1; string username = 2;/* profileInfoはタイプスクリプトでオプションになります。タイプはprofileinfo | null |未定義は、プロファイルに価値を提供したくない場合に必要です。    */optional ProfileInfoプロファイル= 3;/*部門は部門の種類またはnullのみを受け入れるため、利用可能な値がない場合はnullを渡す必要があることを意味します。    */部門= 4;
}

生成されたインターフェイスは次のとおりです。

インターフェイスProfileInfoをエクスポートする{
  ID：番号;
  バイオ：文字列;
  電話：文字列;}インターフェイス部門のエクスポート{
  ID：番号;
  名前：文字列;}インターフェイスユーザーをエクスポートする{
  ID：番号;
  ユーザー名：文字列;
  プロフィール？：ProfileInfo | null |未定義; //これを確認してください
  部門：部門|ヌル; //これをチェックしてください}

• --ts_proto_opt=noDefaultsForOptionals=true 、 undefined原始値は、protobuf仕様に従ってデフォルトではありません。さらに、標準の動作とは異なり、フィールドが標準のデフォルト値に設定されている場合、エンコードされ、ワイヤー上で送信され、未定義の値と区別されます。たとえば、メッセージがブール値を設定しない場合、通常、これはデフォルトでfalseになります。

このオプションにより、ライブラリは、square/blockによって維持および使用されるワイヤの実装を互換性のある方法で動作させることができます。注：このオプションは、このオプションが有効になっている場合、WireまたはTS-Protoを使用して生成された他のクライアント/サーバーコードと組み合わせてのみ使用する必要があります。

NestJSサポート

Nestjsと一緒に作業する素晴らしい方法があります。 ts-proto 、コントローラー、クライアント用のinterfacesとdecorators生成します。詳細については、nestjs readmeを参照してください。

ウォッチモード

Protoファイルの変更ごとにts-proto実行する場合は、Chokidar-Cliなどのツールを使用して、 package.jsonのスクリプトとして使用する必要があります。

 「proto：generate "：" protoc --ts_proto_out =。./<proto_name>/<proto_name> .proto  -  ts_proto_opt = esmoduleinterop = true "、" proto：watch "：" chokidar "**/*。proto"  - c "npm run proto：generate" "

基本的なGRPC実装

ts-protoはRPCフレームワーク不可欠なものです - データソースとの間でデータを送信する方法はあなた次第です。生成されたクライアントの実装はすべて、 rpcパラメーターを期待しています。このタイプは次のように定義されています。

インターフェイスrpc {
  request（service：string、method：string、data：uint8array）：Promise <uint8array>;}

GRPCを使用している場合、簡単な実装が次のようになります。

 const conn = new grpc.client（
  「LocalHost：8765」、
  grpc.credentials.createInsecure（））; type rpcimpl =（service：service：string、method：string、data：uint8array）=> promise <uint8array>; const sendrequest：rpcimpl =（service、method、data）=> {{
  // grpcで従来、リクエストパスのように見えます
  // "package.names.servicename/methodname"、
  //そのような文字列を構築します
  const path = `/$ {service}/$ {method}`;

  新しい約束を返します（（Resolve、拒否）=> {// makeUnaryRequestはコールバックで結果（およびエラー）を送信します//これを約束に変換します！ （err）{return reject（err）;} resolve（res）;}; function passthrough（angy：any）{return argument;} // 、resultCallback）;
  }）;}; const rpc：rpc = {request：sendRequest};

スポンサー

スポンサーへの称賛：

• Ngrokは、TS-Protoの最初のGRPC-WEBサポートに資金を提供しました。

TS-Protoのカスタマイズや会社の優先サポートが必要な場合は、電子メールで私をpingすることができます。

発達

このセクションでは、TS-Protoに直接貢献する方法について説明します。つまり、 protocでts-protoを実行したり、生成されたTypeScriptを使用したりする必要はありません。

要件

• Docker

• yarn - npm install -g yarn

設定

以下のコマンドは、 Dockerがインストールされていることを想定しています。 OS Xを使用している場合は、 Coreutilsをインストールし、 brew install coreutils 。

• 最新のコードについては、リポジトリをご覧ください。

• yarn install実行して、依存関係をインストールします。

• yarn build:testテストテストファイルを生成します。

  これにより、次のコマンドが実行されます。

• proto2ts - integration/**/*.protoファイルでts-protoを実行して.tsファイルを生成します。

• proto2pbjs - 互換性をテストするためにpbjsを使用して参照実装を生成します。

• yarn testを実行します

ワークフロー

• ユースケースの統合テストを追加/更新します

• また、 yarn watchランニングを残すこともできます。

• 必要なts_proto_opt paramsを使用して、新しいintegration/your-new-test/parameters.txtを作成します

• 最小限のintegration/your-new-test/your-new-test.protoスキーマを作成して、ユースケースを再現します

• ユースケースに十分近い既存のintegration/*テストを見つけるか、EGには、ユースケースを再現するために必要なts_proto_optパラメーションに一致するparameters.txtがあります。

• 新しい統合テストを作成する場合：

• your-new-test.protoまたは既存のintegration/*.protoファイルに変更された後、 yarn proto2binを実行します

• integration/your-new-test/some-test.tsユニットテストを追加/更新します。

• ts-protoコード生成ロジックを変更します。

• または、 yarn proto2ts your-new-testて、特定のテストを再コデーブします

• 再びyarn watchランニングを残しても、「正しいことをするだけです」

• 最も重要なロジックは、SRC/main.tsにあります。

• src yarn proto2ts src/*.ts

• yarn test実行して変更を確認します既存のすべてのテストに合格します

• PRをコミットして送信します

• 生成されたコードをチェックインすることが眉をひそめることがありますが、TS-PROTOの主な仕事がコードを生成することであることを考えると、PRSのコードゲンdiffが役立つのは役に立ちます

• yarn format実行して、TypeScriptファイルをフォーマットします。

• 必ずすべての*.proto 、 *.bin 、および*.tsファイルをintegration/your-new-testでgit add

プロジェクトでテストします

手動でyarn build実行する限り、 yarn add ts-proto@./path/to/ts-proto実行することにより、独自のプロジェクトでローカルTS-Protoの変更をテストできます。

Dockerized Protoc

リポジトリには、docker-compose.ymlで構成されているDockerizedバージョンのprotocが含まれています。

既知のバージョンのprotoc使用してプラグインを手動で呼び出す場合に役立ちます。

使用法：

 ＃シェルにProtoc Airasを含めます。Aliase.sh＃通常どおりProtocを実行します。 TS-PROTOディレクトリは/TS-PROTO.PROTOC --PLUGIN =/TS-PROTO/Protoc-Gen-TS_Proto  -  TS_Proto_out =。/output -i =。/protos./8protoc/* .proto#またはあなたのプラグインパスを指定するTS-Protocエイリアスを使用します。

• すべてのパスは、ホストの現在の作業ディレクトリ内の相対パスでなければなりません。 ../許可されていません

• Dockerコンテナ内では、プロジェクトルートへの絶対パスは/ts-protoです

• コンテナは、現在の作業ディレクトリを/hostに取り付け、作業ディレクトリとして設定します。

• aliases.shが調達されると、任意のフォルダーでprotocコマンドを使用できます。

仮定

• TS/ES6モジュール名はProtoパッケージです

トト

• fromJSON / toJSONでの持続時間の文字列ベースのエンコードをサポートする

• oneof=unions-value 2.0のデフォルトの動作にします

• おそらく2.0でforceLongデフォルトを変更すると、デフォルトでforceLong=longに変更する必要があります

• esModuleInterop=true 2.0のデフォルトにします

1つの取り扱い

デフォルトでは、TS-PROTOは、メッセージの「完全に」 oneofフィールドをモデル化します。たとえば、次のようなメッセージがあります。

メッセージfoo {oneof tay_field {string field_a = 1;文字列field_b = 2; }
}

2つのフィールドでFooタイプを生成します： field_a: string | undefined;およびfield_b: string | undefined 。

この出力を使用すると、 if object.field_aとif object.field_b両方を確認する必要があります。一方を設定した場合は、他のものを解明することを忘れないでください。

代わりに、 oneof=unions-valueオプションを使用することをお勧めします。これにより、出力が代数データ型/ADTに変更されます。

 yourmessageインターフェイス{
  どちらかのフィールド？：{$ case： "field_a";値：文字列} | {$ case： "field_b";値：文字列};}

これは、一度に単一の値を持つことができるいずれかeitherFieldフィールドに値が保存されるため、一度にfield_aまたはfield_b 「設定」の1つのみを自動的に強制するためです。

（いずれかのeitherFieldオプションであることに注意してください。プロトブフのb/c oneofは「最大1つのフィールド」が設定されていることを意味し、フィールドの1つを設定する必要があるという意味ではありません。）

TS-Protoの現在廃止されていない2.xリリースでは、 oneof=unions-valueデフォルトの動作になります。

また、各オプションにフィールド名が含まれている組合を生成するoneof=unionsオプションもあります。

 yourmessageインターフェイス{
  どちらかのフィールド？：{$ case： "field_a"; field_a：string} | {$ case： "field_b"; field_b：string};}

これは、コードとタイプを作成して複数のONESオプションを処理するのが難しい場合があるため、推奨されなくなりました。

1つのタイプのヘルパー

次のヘルパータイプにより、 oneof=unionsから生成されたタイプで作業しやすくなる場合がありますが、 oneof=unions-value使用する場合は必要ありません。

 /** 1つのフィールドからすべてのケース名を抽出します。 */Type Oneofcases <t> = t extends {$ case：推測u extends string}？ u：unnewer;/** 1つのフィールドからすべての値タイプの結合を抽出します*/type oneofvalues <t> = t extends {$ case：us u extends string; [キー：文字列]：不明}？ T [u]：決して;/**そのフィールド名に基づいて特定のタイプの1つのケースを抽出します*/タイプのOneofcase <t、kはOneofcase <t >> = t拡張{
  $ case：k;
  [キー：文字列]：不明;}
  ？ t
  ：決して;/** 1つのフィールドから特定のタイプの値タイプを抽出します*/type oneofvalue <t、kはoneofcases <t >> = t extends {
  $ case：推測uはkを拡張します。
  [キー：文字列]：不明;}
  ？ t [u]
  ： 一度もない;

比較のために、 oneof=unions-valueの同等物：

 /** 1つのフィールドからすべてのケース名を抽出します。 */タイプOneofcases <t> = t ['$ case'];/** 1つのフィールドからすべての値タイプの結合を抽出します*/type oneofvalues <t> = t ['value'];/**抽出そのフィールド名に基づいた特定のタイプの1つのケース */タイプOneofcase <t、kはOneofcase <t >> = t拡張{
  $ case：k;
  [キー：文字列]：不明;}
  ？ t
  ：決して;/** 1つのフィールドから特定のタイプの値タイプを抽出します*/type oneofvalue <t、kはoneofcases <t >> = t extends {
  $ case：推測uはkを拡張します。
  値：不明;}
  ？ t [u]
  ： 一度もない;

デフォルト値と未解決のフィールド

Core Protobuf（およびts-protoと同様）では、デフォルト値または等しい値がワイヤー上に送信されない値が送信されません。

たとえば、メッセージのデフォルト値はundefinedです。プリミティブタイプは、自然なデフォルト値を取得します。たとえば、 stringは'' 、 numberは0などです。

Protobufは、古いエージェントによって省略された場合でも、プリミティブフィールドには常に価値があるため、順方向の互換性を可能にするため、この動作を選択/強制します。

これは良いことですが、デフォルト値と未解決の値をts-protoフィールドで区別できないことも意味します。それは基本的にプロトブフの仕組みです。

セット/リンクセットを検出できるプリミティブフィールドが必要な場合は、ラッパータイプを参照してください。

エンコード /デコード

ts-proto ProtoBUFルールに従い、バイナリ形式でシリアル化されたときに出力からそれらを省略しながら、デコード時に設定フィールドのデフォルト値を常に返します。

 syntax = "proto3"; message foo {string bar = 1;
}

 protobufbytes; //これは、Protobuf binary formatfoo.decode（protobufbytes）の空のfooオブジェクトであると仮定します。 // => {bar： ''}

 foo.encode（{bar： ""}）; // => {}、Protobufバイナリ形式で空のfooオブジェクトを書き込みます

json / tojsonから

JSONの読み取りは、デフォルト値も初期化します。送信者は、未解決のフィールドを省略するか、デフォルト値に設定する場合があるため、 fromJSONを使用して入力を正規化します。

 foo.fromjson（{}）; // => {bar： ''} foo.fromjson（{bar： ""}）; // => {bar： ''} foo.fromjson（{bar： "baz"}）; // => {bar： 'baz'}

JSONを書くとき、 ts-protoデフォルト値に設定されている非セットフィールドとフィールドを省略することにより、メッセージを正規化します。

 foo.tojson（{}）; // => {} foo.tojson（{bar：undefined}）; // => {} foo.tojson（{bar： ""}）; // => {}  - 注：expectionfoo.tojson（{bar： "baz"}）として、デフォルト値を省略します。 // => {bar： 'baz'}

よく知られているタイプ

Protobufには、「よく知られたタイプ」と呼ばれるいくつかの事前定義されたメッセージ定義が付属しています。それらの解釈はProtoBUF仕様によって定義され、ライブラリはこれらのメッセージをターゲット言語の対応するネイティブタイプに変換することが期待されています。

ts-proto現在、これらのメッセージを対応するネイティブタイプに自動的に変換しています。

• boolean

• Uint8Array

• google.protobuf.doublevalue⇆ number

• google.protobuf.fieldmask⇆string string[]

• google.protobuf.floatvalue⇆ number

• google.protobuf.int32value⇆ number

• google.protobuf.int64value⇆ number

• google.protobuf.listvalue any[]

• google.protobuf.uint32value⇆ number

• google.protobuf.uint64value⇆ number

• google.protobuf.stringvalue⇆ string

• google.protobuf.value any （ number | string | boolean | null | array | object ）

• google.protobuf.struct⇆ { [key: string]: any }

ラッパータイプ

ラッパータイプは、単一のプリミティブフィールドを含むメッセージであり、 import "google/protobuf/wrappers.proto" .protoファイルにインポートできます。

これらはメッセージであるため、デフォルト値はundefinedため、ラッパータイプを使用する場合、デフォルト値とデフォルト値を区別できます。 ts-protoこれらのフィールドを<primitive> | undefinedとして生成します<primitive> | undefined 。

例えば：

 // protobufsyntax = "proto3"; Import "Google/protobuf/wrappers.proto"; message examplemessage {google.protobuf.stringvalue name = 1;
}

 // typeScriptInterface examplemessage {
  名前：文字列|未定義;}

メッセージをエンコードすると、プリミティブ値が対応するラッパータイプに戻されます。

 ExamPlemessage.Encode（{name： "foo"}）; // => {name：{value： 'foo'}}、binary

Tojsonを呼び出すとき、ラッパータイプはJSONで慣用的であるため、値は変換されません。

 Examplemessage.tojson（{name： "foo"}）; // => {name： 'foo'}

JSONタイプ（構造タイプ）

JSONには事前に不明な値が含まれている可能性があるため、Protobufの言語とタイプはすべてのJSON値を表すのに十分ではありません。このため、Protobufは任意のJSON値を表すためにいくつかの追加のタイプを提供します。

これらはstructタイプと呼ばれ、 import "google/protobuf/struct.proto" .protoファイルにインポートできます。

• google.protobuf.value⇆ any

• これは最も一般的なタイプであり、任意のJSON値（IE number | string | boolean | null | array | object ）を表すことができます。

• google.protobuf.listvalue any[]

• JSONアレイを表す

• google.protobuf.struct⇆ { [key: string]: any }

• JSONオブジェクトを表す

ts-proto 、これらの構造体タイプと対応するJSONタイプの間で自動的に前後に変換されます。

例：

 // protobufsyntax = "proto3"; Import "Google/protobuf/struct.proto"; message Examplemessage {google.protobuf.value Anyty Anyty = 1;
}

 // typeScriptInterface examplemessage {
  何でも：任意の|未定義;}

メッセージに埋め込まれたJSON値をエンコードすると、それをstructタイプに変換します。

 Examplemessage.Encode（{Anything：{name： "hello"}}）;/*次の構造を出力します。 value {stringvalue = "hello"}]}}}}*/examplemessage.encode（{Anything：true}）;/* protobufバイナリ形式でエンコードされた次の構造を出力します：{anything：value {boolvalue = true}}}}} */

タイムスタンプ

google.protobuf.Timestampの表現は、 useDateフラグで構成可能です。 useJsonTimestampフラグは、 useDateている場合の精度をfalse制御します。

Protobufよく知られたタイプ	default/ useDate=true	useDate=false	useDate=string	useDate=string-nano
google.protobuf.Timestamp	Date	{ seconds: number, nanos: number }	string	string

使用する場合、 useDate=falseおよびuseJsonTimestamp=rawタイムスタンプは{ seconds: number, nanos: number }として表されますが、ナノ秒の精度があります。

使用する場合、 useDate=string-nanoタイムスタンプは、ナノ秒の精度1970-01-01T14:27:59.987654321ZのISO文字列として表され、変換のためにNano-Dateライブラリに依存しています。プロジェクトにインストールする必要があります。

数字タイプ

数字は、デフォルトではプレーンJavaScript number sであると想定されています。

これは、 int32やfloatなどのプロトブフタイプには適していますが、 int64のような64ビットタイプはJavaScriptのnumberタイプで100％表現することはできません。INT64 int64 numberよりも大きい/小さいためです。

TS-Protoのデフォルト構成（ forceLong=number ）は、64ビットフィールドにnumberを使用し、値（実行時に）がNumber.MAX_SAFE_INTEGERよりも大きい場合にエラーをスローすることです。

64ビット /より高いMAX_SAFE_INTEGER値を使用すると予想される場合は、TS-Proto forceLongオプションを使用して、長いnpmパッケージを使用して64ビット値の全範囲をサポートします。

Protobuf Numberタイプは、 forceLong構成オプションに基づいてJavaScriptタイプにマッピングされます。

プロトブフ番号タイプ	デフォルト/ forceLong=number	forceLong=long	forceLong=string
ダブル	番号	番号	番号
フロート	番号	番号	番号
INT32	番号	番号	番号
INT64	番号*	長さ	弦
UINT32	番号	番号	番号
UINT64	番号*	符号なしの長い	弦
SINT32	番号	番号	番号
SINT64	番号*	長さ	弦
固定32	番号	番号	番号
固定64	番号*	符号なしの長い	弦
sfixed32	番号	番号	番号
sfixed64	番号*	長さ	弦

ここで、（*）は、実行時にエラーを投げる可能性があることを示します。

オプションの値の現在のステータス

• 必要なプリミティブ：AS-IS、IE string name = 1を使用します。

• オプションのプリミティブ：ラッパータイプ、つまりStringValue name = 1を使用します。

• 必要なメッセージ：利用できません

• オプションのメッセージ：AS-IS、つまりSubMessage message = 1を使用します。