Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: option to declare schema as const #1096

Merged
merged 4 commits into from
Sep 4, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions README.markdown
Original file line number Diff line number Diff line change
Expand Up @@ -456,6 +456,8 @@ Generated code will be placed in the Gradle build directory.

- With `--ts_proto_opt=outputSchema=true`, meta typings will be generated that can later be used in other code generators. If outputSchema is instead specified to be `no-file-descriptor` then we do not include the file descriptor in the generated schema. This is useful if you are trying to minimize the size of the generated schema.

- With `--ts_proto_opt=outputSchemaAsConst=true`, the `protoMetadata` export of `outputSchema=true` is declared using `as const` and `satisfies` (supported by TypeScript since [4.9](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html#the-satisfies-operator)), providing more detailed type information.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @cmd-johnson ! Wdyt of making outputSchema a tristate, like outputSchema=const would enable this behavior, vs. a net-new flag? We've done that with a few other flags and it's seemed nice so far.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I wanted to do at first, but outputSchema already can be true or no-file-descriptor, which would mean that adding an as const option would also require adding a no-file-descriptor-as-const option or make the option's type an array of a new OutputSchema enum (similar to how outputServices works) and I didn't want to update all usages of no-file-descriptor 😅.

If you'd rather go that route than adding another parameter, I can make those changes. I'd prefer going the enum array route in that case, because it scales better if more options get added to the outputSchema flag at some point in the future.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yep! I was wondering if we'd run into that.

The enum array of outputSchema=no-file-descriptor,const,etc approach would be great, since you don't mind; thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!
I've made it so you can combine the flags by specifying it multiple times, which is the way the outputServices flag works:

--ts_proto_opt=outputSchema=const,outputSchema=no-file-descriptor


- With `--ts_proto_opt=outputTypeAnnotations=true`, each message will be given a `$type` field containing its fully-qualified name. You can use `--ts_proto_opt=outputTypeAnnotations=static-only` to omit it from the `interface` declaration, or `--ts_proto_opt=outputTypeAnnotations=optional` to make it an optional property on the `interface` definition. The latter option may be useful if you want to use the `$type` field for runtime type checking on responses from a server.

- With `--ts_proto_opt=outputTypeRegistry=true`, the type registry will be generated that can be used to resolve message types by fully-qualified name. Also, each message will be given a `$type` field containing its fully-qualified name.
Expand Down
Loading
Loading