Getting to 1.0

[koblas]

This is putting in a handful of notes. I would like to help push this package to a formal 1.0 release so that it can get better adoption. I'm selfish in that way which is I want to make sure I've got stable programs that I'm building against that have more maintainers...

There are a handful of things that I perceive that might help:

• Moving the codebase to TypeScript -- just makes it look better to outsiders
• Issues: Windows
• Issues: CamelCase
• Issues: Namespaces
• definition in Unimplemented Service Definitions - it feels wrong to a first read
• Extra imports when not used
• Escaping of reserved words (not gonna fix it.)
• grpc-web client/support

Anything else?

[thesayyn]

This is the exact list of this that I want to fix before the end of this year. Unfortunately, I don’t have that much free time as I used to have.

• Issues: Windows -> this is something i am gonna pick up again really soon.

• Issues: CamelCase -> i will need help but i can’t accept a PR that sets this as the default behavior. it has to be controller via ts_opt flag. Also, snake_case is not that what we force on users. you get whatever you name your field so. this has never been my code style bias.

• Issues: Namespaces -> same as CamelCase

• Extra imports when not used

• Escaping of reserved words: I will need help

• definition in Unimplemented Service Definitions - it feels wrong to a first read: I am open to any other suggestions

[thesayyn]

Also #80, #86, #51

[koblas]

I've got time I can pull out of a few project to help.

I'm going to start with moving to formal TypeScript since I've got a strong bias into making sure the system is helping me with types and I do find it annoying to have to keep comments in sync.

There are some things that I think are breaking changes, it's probably good to target those at 1.0 since it's a major release and can justify breaking compatibility.

[thesayyn]

There are some things that I think are breaking changes, it's probably good to target those at 1.0 since it's a major release and can justify breaking compatibility.

I strongly agree with that.

I've got time I can pull out of a few projects to help.

I'd be happy to see you or any other contributor out there working on the issues.

[thesayyn]

also #82

[cortopy]

• grpc-web client/support

Which implementation would be the target? I personally use the improbable one because bundle size is much smaller than google's and supports binary for streams. So if I may, I'd like to vote for that one

[thesayyn]

• grpc-web client/support

Which implementation would be the target? I personally use the improbable one because bundle size is much smaller than google's and supports binary for streams. So if I may, I'd like to vote for that one

If both of them (google one, improbable one) have feature and public API parity, then we would like to support them both. . Personally, I don't like imposing choices on people.

[thesayyn]

Now that the windows issue is gone (and we test against windows as well), we can safely move on and add new features to the plugin. @koblas

[thesayyn]

#98 is here but it still needs a bit of work.

[thesayyn]

#132 has been merged.

[thesayyn]

All the items here are done. closing