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: Add js type support #1030

Merged
merged 6 commits into from
Apr 30, 2024
Merged

Conversation

dasco144
Copy link
Contributor

Closes #958

@dasco144 dasco144 changed the title Add js type support feat: Add js type support Apr 16, 2024
@dasco144 dasco144 force-pushed the add-js_type-support branch 4 times, most recently from bba5cb0 to a53ca78 Compare April 16, 2024 13:56
Comment on lines +3 to +4
// @ts-ignore
import Long = require("long");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure how to resolve this at the moment. In my editor it errors, stating that the tsconfig esModuleInterop is enabled for this file and I can't use an Import assignment, but from what I can see at runtime it does not have esModuleInterop enabled.

If we import using a default import

import Long from "long";

then the editor no longer reports an error, but tests fail due to it not being able to resolve the import.

@dasco144 dasco144 marked this pull request as ready for review April 16, 2024 15:18
@dasco144 dasco144 force-pushed the add-js_type-support branch from be024fb to d1ed693 Compare April 20, 2024 20:39
@stephenh
Copy link
Owner

Hi @dasco144 , thanks for the PR! Just wanted to say it'll probably be ~few days/this weekend before I get a chance to look at it.

@dasco144
Copy link
Contributor Author

Hi @dasco144 , thanks for the PR! Just wanted to say it'll probably be ~few days/this weekend before I get a chance to look at it.

Thanks! Let me know if I need to change anything 💪

Copy link
Owner

@stephenh stephenh left a comment

Choose a reason for hiding this comment

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

Hi @dasco144 , this is great! The test coverage is especially amazing, and appreciated! Just a few questions, mostly for my own understanding, but otherwise lgtm!

case FieldOptions_JSType.JS_STRING:
return FieldDescriptorProto_Type.TYPE_STRING;
case FieldOptions_JSType.JS_NUMBER:
return FieldDescriptorProto_Type.TYPE_INT64;
Copy link
Owner

Choose a reason for hiding this comment

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

Do we need to handle the JS_NORMAL value here?

https://googleapis.dev/nodejs/nodejs-functions/latest/google.protobuf.FieldOptions.html

If not, maybe put an in-source comment about why not? Like maybe if JS_NORMAL is used, the jstype ends up being undefined because JS_NORMAL is an 0th value enum (just guessing!)...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From my understanding, the JS_NORMAL case would be equivalent to not having the JSType set on the field at all, so we want the behaviour to match the same case as if it were undefined. That's why I made it fallthrough and default to not returning an explicit value.
I'll add a quick comment explaining this 👍
I could also maybe move it into the guard clause above

if (
(isLong(field) || isLongValueType(field)) &&
options.forceLong === LongOption.LONG &&
!isJsTypeFieldOption(options, field)
Copy link
Owner

Choose a reason for hiding this comment

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

Just curious, but we don't have any other isJsTypeFieldOption checks in here, but I imagine maybe that's because the types will line-up (for anything not this forceLong case?) and so we don't need any special handling?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, exactly that. These cases will fall through to the isPrimitive check below, and just output reading from the variable as is (without any special method calls or handling)

@stephenh
Copy link
Owner

Sweet, this is amazing @dasco144 , thank you!

@stephenh stephenh merged commit 0dd951b into stephenh:main Apr 30, 2024
6 checks passed
stephenh pushed a commit that referenced this pull request Apr 30, 2024
# [1.173.0](v1.172.0...v1.173.0) (2024-04-30)

### Features

* Add js type support ([#1030](#1030)) ([0dd951b](0dd951b)), closes [#958](#958)
@stephenh
Copy link
Owner

🎉 This PR is included in version 1.173.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@dasco144
Copy link
Contributor Author

I realised I did not update the [README.markdown](https://github.com/stephenh/ts-proto/blob/main/README.markdown) explaining this setting. I'll create a new PR to add this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for FieldOptions.JSType
2 participants