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

fix: Add check for lower bound with forceLong=number #1057

Merged
merged 6 commits into from
Jun 7, 2024

Conversation

timostamm
Copy link
Contributor

@timostamm timostamm commented Jun 6, 2024

With default plugin options, or useJsTypeOverride for a field with option jstype = JS_NUMBER, 64-bit integral values are converted to a JavaScript Number when decoding from binary. When a value is too large for Number, an error is thrown.

But signed integers can also be too small for Number. This PR adds a check for the lower bound.

src/main.ts Outdated Show resolved Hide resolved
src/main.ts Outdated Show resolved Hide resolved
src/main.ts Outdated Show resolved Hide resolved
src/main.ts Outdated Show resolved Hide resolved

if (_m0.util.Long !== Long) {
_m0.util.Long = Long as any;
_m0.configure();
Copy link
Owner

Choose a reason for hiding this comment

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

@timostamm might be a moot point in the long run, but I think this "hook up Long to protobufjs and call configure" is required, and had been using a ts-poet-ism to get like auto-inserted into the output on the conditional use of Long in the output...

So the otherwise-lgtm change of using the { toString(): string } meant ts-poet doesn't know to implicitly add this anymore (which is admittedly kind of cute/too-cute on how its gets added).

Am I missing something, where this isn't actually required? The intent was just to have it "just work" for users, and not need to do this themselves. If we should keep it, we can probably figure out another way to get it conditionally into the output...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let's add it back 👍 I'll take a look tomorrow.

Copy link
Contributor Author

@timostamm timostamm Jun 7, 2024

Choose a reason for hiding this comment

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

Uh, I remember what's going on with protobuf.js and Long.js, and I wish I didn't.

protobufjs automagically loads long from node_modules, and uses it in Reader. If the magic fails (easily happens with bundlers), it falls back to an alternative and returns Number instead of Long.

We could hook the ConditionalOutput to Reader.int64 instead. Then we're free to refactor longToNumber. Doesn't seem like a good idea because the magic behavior is difficult to test.

src/main.ts Outdated Show resolved Hide resolved
@timostamm
Copy link
Contributor Author

I don't think it's worth going through the the long conversion refactor, see #1057 (comment).

Updated the PR to just add the check for lower bounds.

@stephenh stephenh merged commit 01ef3c3 into stephenh:main Jun 7, 2024
7 checks passed
stephenh pushed a commit that referenced this pull request Jun 7, 2024
## [1.176.3](v1.176.2...v1.176.3) (2024-06-07)

### Bug Fixes

* Add check for lower bound with forceLong=number ([#1057](#1057)) ([01ef3c3](01ef3c3))
@stephenh
Copy link
Owner

stephenh commented Jun 7, 2024

🎉 This PR is included in version 1.176.3 🎉

The release is available on:

Your semantic-release bot 📦🚀

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.

2 participants