ts-proto 1.137.0 → 1.137.2

package/README.markdown

@@ -5,8 +5,6 @@
 
 > `ts-proto` transforms your `.proto` files into strongly-typed, idiomatic TypeScript files!
 
-(Note, if you're a new user of ts-proto and using a modern TS setup with `esModuleInterop`, or want to use ts-proto in ESM / snowpack / vite, you need to also pass that as a `ts_proto_opt`.)
-
 ## Table of contents
 
 - [ts-proto](#ts-proto)
@@ -14,6 +12,7 @@
 - [Overview](#overview)
 - [QuickStart](#quickstart)
   - [Buf](#buf)
+  - [ESM](#esm)
 - [Goals](#goals)
 - [Example Types](#example-types)
 - [Highlights](#highlights)
@@ -118,6 +117,13 @@ plugins:
       - useExactTypes=...
 ```
 
+## ESM
+
+If you're using a modern TS setup with either `esModuleInterop` or running in an ESM environment, you'll need to pass `ts_proto_opt`s of:
+
+* `esModuleInterop=true` if using `esModuleInterop` in your `tsconfig.json`, and
+* `importSuffix=.js` if executing the generated ts-proto code in an ESM environment
+
 # Goals
 
 In terms of the code that `ts-proto` generates, the general goals are:
@@ -283,7 +289,9 @@ Generated code will be placed in the Gradle build directory.
 
 - With `--ts_proto_opt=forceLong=long`, all 64-bit numbers will be parsed as instances of `Long` (using the [long](https://www.npmjs.com/package/long) library).
 
-  Alternatively, if you pass `--ts_proto_opt=forceLong=string`, all 64-bit numbers will be outputted as strings.
+  With `--ts_proto_opt=forceLong=string`, all 64-bit numbers will be output as strings.
+
+  With `--ts_proto_opt=forceLong=bigint`, all 64-bit numbers will be output as `BigInt`s. This option still uses the `long` library to encode/decode internally within `protobuf.js`, but then converts to/from `BigInt`s in the ts-proto-generated code.
 
   The default behavior is `forceLong=number`, which will internally still use the `long` library to encode/decode values on the wire (so you will still see a `util.Long = Long` line in your output), but will convert the `long` values to `number` automatically for you. Note that a runtime error is thrown if, while doing this conversion, a 64-bit value is larger than can be correctly stored as a `number`.
 
@@ -567,7 +575,7 @@ The commands below assume you have **Docker** installed. To use a **local** copy
 
 - Check out the [repository]() for the latest code.
 - Run `yarn install` to install the dependencies.
-- Run `yarn build:test` or `yarn build:test:local` to generate the test files.
+- Run `yarn build:test` to generate the test files.
   > _This runs the following commands:_
   >
   > - `proto2bin` — Converts integration test `.proto` files to `.bin`.
@@ -577,25 +585,24 @@ The commands below assume you have **Docker** installed. To use a **local** copy
 
 **Workflow**
 
-- Modifying the plugin implementation:
-  - The most important logic is found in [src/main.ts](src/main.ts).
-  - Run `yarn bin2ts` or `yarn bin2ts:local`.  
-    _Since the proto files were not changed, you only need to regenerate the typescript files._
-  - Run `yarn test` to verify the typescript files are compatible with the reference implementation, and pass other tests.
-- Updating or adding `.proto` files in the integration directory:
-  - Run `yarn watch` to automatically regenerate test files when proto files change.
-    - Or run `yarn build:test` to regenerate all integration test files.
-  - Run `yarn test` to retest.
-
-**Contributing**
-
-- Run `yarn build:test` and `yarn test` to make sure everything works.
-- Run `yarn format` to format the typescript files.
-- Commit the changes:
-  - Also include the generated `.bin` files for the tests where you added or modified `.proto` files.
-    > These are checked into git so that the test suite can run without having to invoke the `protoc` build chain.
-  - Also include the generated `.ts` files.
-- Create a pull request
+- Add/update an integration test for your use case
+  - Either find an existing `integration/*` test that is close enough to your use case, e.g. has a `parameters.txt` that matches the `ts_proto_opt` params necessary to reproduce your use case
+  - If creating a new integration test:
+    - Make a new `integration/your-new-test/parameters.txt` with the necessary `ts_proto_opt` params
+    - Create a minimal `integration/your-new-test/your-new-test.proto` schema to reproduce your use case
+  - After any changes to `your-new-test.proto`, or an existing `integration/*.proto` file, run `yarn proto2bin`
+    - You can also leave `yarn watch` running, and it should "just do the right thing"
+  - Add/update a `integration/your-new-test/some-test.ts` unit test, even if it's as trivial as just making sure the generated code compiles
+- Modify the `ts-proto` code generation logic:
+  - Most important logic is found in [src/main.ts](src/main.ts).
+  - After any changes to `src/*.ts` files, run `yarn bin2ts` to re-codegen all integration tests
+    - Or `yarn bin2ts your-new-test` to re-codegen a specific test
+    - Again leaving `yarn watch` running should "just do the right thing"
+- Run `yarn test` to verify your changes pass all existing tests
+- Commit and submit a PR
+  - Run `yarn format` to format the typescript files.
+  - Make sure to `git add` all of the `*.proto`, `*.bin`, and `*.ts` files in `integration/your-new-test`
+    - Sometimes checking in generated code is frowned upon, but given ts-proto's main job is to generate code, seeing the codegen diffs in PRs is helpful
 
 **Dockerized Protoc**
 

package/build/encode.js

@@ -12,7 +12,11 @@ function generateEncoder(ctx, typeName) {
     }
     if (name == "Timestamp") {
         const TimestampValue = (0, utils_1.impProto)(ctx.options, "google/protobuf/timestamp", name);
-        return (0, ts_poet_1.code) `${TimestampValue}.encode(${ctx.utils.toTimestamp}(value)).finish()`;
+        let value = (0, ts_poet_1.code) `value`;
+        if (ctx.options.useDate === options_1.DateOption.DATE || ctx.options.useDate === options_1.DateOption.STRING) {
+            value = (0, ts_poet_1.code) `${ctx.utils.toTimestamp}(${value})`;
+        }
+        return (0, ts_poet_1.code) `${TimestampValue}.encode(${value}).finish()`;
     }
     if (name == "Struct") {
         const StructType = (0, utils_1.impProto)(ctx.options, "google/protobuf/struct", name);
@@ -54,7 +58,11 @@ function generateDecoder(ctx, typeName) {
     let TypeValue;
     if (name == "Timestamp") {
         TypeValue = (0, utils_1.impProto)(ctx.options, "google/protobuf/timestamp", name);
-        return (0, ts_poet_1.code) `${TypeValue}.decode(value)`;
+        const decoder = (0, ts_poet_1.code) `${TypeValue}.decode(value)`;
+        if (ctx.options.useDate === options_1.DateOption.DATE || ctx.options.useDate === options_1.DateOption.STRING) {
+            return (0, ts_poet_1.code) `${ctx.utils.fromTimestamp}(${decoder})`;
+        }
+        return decoder;
     }
     if (name == "Struct" || name == "ListValue") {
         TypeValue = (0, utils_1.impProto)(ctx.options, "google/protobuf/struct", name);

package/build/main.js

@@ -904,10 +904,11 @@ function generateEncode(ctx, fullName, messageDesc) {
             else {
                 // Ideally we'd reuse `writeSnippet` but it has tagging embedded inside of it.
                 const tag = ((field.number << 3) | 2) >>> 0;
+                const rhs = (x) => ((0, types_1.isLong)(field) && options.forceLong === options_1.LongOption.BIGINT ? `${x}.toString()` : x);
                 const listWriteSnippet = (0, ts_poet_1.code) `
           writer.uint32(${tag}).fork();
           for (const v of message.${fieldName}) {
-            writer.${(0, types_1.toReaderCall)(field)}(v);
+            writer.${(0, types_1.toReaderCall)(field)}(${rhs("v")});
           }
           writer.ldelim();
         `;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ts-proto",
-  "version": "1.137.0",
+  "version": "1.137.2",
   "description": "",
   "main": "build/plugin.js",
   "repository": "github:stephenh/ts-proto",