-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
typescript definitions meta-issue #718
Comments
It seems that, no matter how this is done, that there'll always be some issues. For example, the minimal long interface has been introduced to handle the fact that long.js is optional. This solves the issue in most cases, but introduces new edge cases. Similarly, previously all buffers were simply documented as being an Related: #711 Long story short: I haven't found a way yet to make this work for all edge cases. Even generating multiple definition files, one for node and one for the browser, would introduce an inconvenient setup step to configure the correct file(s). |
What's the issue? Perhaps a reasonable solution is simply not to make it optional? I'm sure there is context I'm missing.
Seems to me that this is exactly what's needed, with a flag to The other two issues I mentioned are with generated code - can they also be solved with flags to |
Well, not everyone needs full 64 bit support (JS numbers are safe up to 53 bits). If long.js isn't available, protobuf.js falls back to using numbers - and the user can safe quite a bit of bundle size. |
Ah, fair enough. In that case, this can also be solved with another variant a la |
Hmm, well, yeah. I'd favor something generalized, but that might be the only working solution. We'd then have:
Hmm .... |
That's a large matrix, but I don't know of another way. You'll also need to split the definitions (they currently are shared) to support real-long vs stub-long. |
I've added another bullet to the list:
|
Maybe also related: #717 If you have any exact requirements for Edit: Sorry, needed multiple edits to get the referenced issue right. |
Ah, looks like you just implemented that in #717. Awesome. |
This commit removes minimal type definitions from the library's default definitions and moves them to stubs instead: Removing @types/node and/or @types/long would normally result in a tsc error, which can now be circumvented by referencing the stubs instead were either of these integrations is not wanted. For example, the following replaces both (browser only, no long.js): /// <reference path="node_modules/protobufjs/stub-long.d.ts" />
/// <reference path="node_modules/protobufjs/stub-node.d.ts" /> With this in place we could now either create a matrix of entry points that'd only differ in their references or leave this up to the developer as a configuration step. Because of the amount of necessary entry points I'd favor the latter. |
Nice. I'll try this stuff out shortly. Just one issue remaining, AFAICT, and I've marked that in the issue description. |
The 2nd commit should cover this. It now emits |
Yeah there's still the issue of number|Long, though.
…On Mar 23, 2017 6:34 PM, "Daniel Wirtz" ***@***.***> wrote:
The 2nd commit should cover this. It now emits Long instead of
$protobuf.Long.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#718 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPMl6cQOJ_3PmqW3lK43Mrh4sOgnIks5rovNkgaJpZM4Mm9e6>
.
|
Well, this is still correct in some way. Even if you are not using long.js at all, you can still call a method with a proper Possible workaround: Alias |
This should do. |
This changes the return values. Note that messages properties can still be ´number|Long` because both is valid/supported as long as JS numbers are safe integers (<= 2^53). |
… of 'number|Long' (only relevant with long.js), see #718
This now basically does what you want, I believe: Without long.js
With long.js
This does not affect return types of Reader-methods etc. (always uses Note that |
protobuf.js version: 6.6.5
First, thank you for including typescript support! I was delighted to discover that I could stop using https://github.com/sintef-9012/Proto2TypeScript.
However, there are a few problems with the generated and bundled TS definitions:
interface Long
makes it impossible to chainLong
methods on fields; e.g.d.timestampNanos.toNumber()
becomesd.timestampNanos as Long).toNumber()
generated type
of certain numeric fields isnumber|Long
, which also makes it impossible to chainLong
methods; i.e. it becomes necessary to coalesce or cast toLong
before being able to use the field value.Buffer
, which is only available in Node.js. In CockroachDB we are using protobuf.js in the browser, and would like to avoid including type definitions for Node.js types which will not be available at run time.The text was updated successfully, but these errors were encountered: