v0.5.0 is missing from npm

[rmm5t]

• GitHub Releases shows v0.5.0.
• NPM only shows v0.4.2.

Will a maintainer please npm publish v0.5.0?

---

Known workarounds in the meantime:

npm install coinbase/gdax-node
or
yarn add coinbase/gdax-node

---

Overall, there is a lack of discipline on this project with regards to releases:

• Haphazard and missing release notes
• Missing tags for releases that are on NPM
• Missing NPM releases for tags that are on the project.
• Violations of semver
• Automation-wise, it's evident that neither yarn version nor npm version and npm publish are not used properly (nor at the same times) when actually building new releases; otherwise, the tagging and NPM publishing history wouldn't be the mess that it currently is.

---

UPDATE: There's now a v0.5.1 release on NPM (skipping v0.5.0), but this release violated semver and there's no associated tag on the repository. I think this particular issue should remain open until we fix the conventions around release management (hopefully as part of a v0.6.0 release).

[rmm5t]

/cc @cilphex, @fb55, @mihar

[BrandonCopley]

I can help update the npm module, it's a really easy push. It wouldn't be secure, but maybe someone on Gdax could push v0.5.0 up to NPM

[rmm5t]

UPDATE: @fb55 got in touch with me and we've started to move this project forward.

---

@BrandonCopley I've sent multiple emails to @mihar and tweeted him about volunteering to help maintain this project. No response in 2 3 weeks. 😞

If anyone else has the keys and would like me to help maintain this project (and the published NPM package), I'm making myself available. Please feel free to review my open pull-requests on this project. Feel free to review my GitHub open-source history and my StackOverflow profile for credentials.

Here's a quick summary of what I think should be a priority for gdax-node, and I'm open to hearing other people's thoughts on the matter:

• Improve process for stable releases (including versioning, publishing, and documenting).
• Move towards a more stable v1.0 release (along with careful considerations of backwards-incompatible changes and interim releases leading up to a v1.0 release).
• Improve test coverage.
• Improve test suite build matrix for different dependency permutations (using circleci workflows or travisci matrices). (See Switch to Travis CI build matrix #250)
• Make the method signatures more consistent between one another.
• Most function arguments are optional or have defaults. Move toward a more consistent usage of "keyword" using destructuring object parameters.
• Make the PublicClient and AuthenticatedClient more consistent between one another. Deprecate inconsistencies while providing a clean set of method signatures for moving forward. (See Normalize PublicClient with AuthenticatedClient  #178)
• Make the WebsocketClient more resilient. Enable the heartbeat channel by default. (See Fix heartbeat channel subscriptions #150)
• Make the WebsocketClient auto-reconnect if disconnected, etc.
• Refactor auth object to { key, secret, passphrase } (See Refactor auth object to { key, secret, passphrase } #151)
• Simplify OrderbookSync constructor signature (See Simplify OrderbookSync constructor signature #177)
• Expose AuthenticatedClient#placeOrder() function (See Expose AuthenticatedClient#placeOrder() function #149)
• Respond to and/or clean out the open Issue and Pull-Request queue.
• Fix error handling (See Fix request error handling #210)

[ghost]

This needs to be fixed for zenbot.

[rmm5t]

Adding a reference to my long comment/rant about publishing minor version releases, because it's relevant to this Issue:

#178 (comment)

---

Regarding npm releases: How do you feel about doing 1.0 beta releases?

@fb55 For this project (and almost all open source projects), I'm always going to advocate for more frequent minor releases vs one large major release drop. Here, this means at least an official v0.5 (back) release and a v0.6 release prior to going to v1.0.

Reasons:

1. When true deprecations are introduced to a codebase (as they are in this PR), it's imperative that those deprecations get published out in a minor release as soon as possible. It's best to have the community run into them early and fix the warnings before the deprecation warnings are eventually removed.
2. When a major version bump happens, the deprecations should be removed, and the codebase made as clean as possible (avoiding the old deprecation conditional checks).
3. Almost no one tests beta or rc1 (release candidate) releases. They are only valuable for really large progjects (operating systems, web frameworks, languages) and/or really popular projects that have large upgrade paths and potentially untested territory. This project is much too small to glean any kind of benefit from a beta release.
4. True and more-frequent semver'd releases allow developers to more easily peg themselves to an older version of a library if they don't yet have the time to perform a major upgrade. It not only improves stability amongst the community, but it also instills confidence in the open source library itself and the maintainers themselves.

In summary, an official beta release will yield almost no benefit to this project. Frequent minor releases will get used and allow us to iterate more quickly and with more confidence.

---

Also, with all that said, even with this PR's normalization of PublicClient and AuthenticationClient, I think there is still room to improve the method signatures through the library.

1. Positional arguments for a library like this that wraps another REST API makes little sense. I think we should move this library towards keyword arguments as much as possible.
   1. Keyword arguments better document themselves.
   2. Keyword arguments allow for easier forwards compatibility changes. We can add features without affecting existing codebases.
2. The constructor for PublicClient and AuthenticationClient still don't match. This is a code-smell from an objected-oriented perspective. Both should use keyword arguments. This would allow you to instantiate either client interchangeably based on a variable pointing at the class as long as you expect to use the parent interface. e.g. This would further cleanup the OrderbookSync internal implementation.

Another concrete example:

// Existing API signature (positional arguments make things unnecessarily messy)
const ob = new OrderBookSync(['BTC-USD'],  'https://api.gdax.com', 'wss://ws-feed.gdax.com', { key, secret, passphrase })

//  Future potential API signature (far superior with keyword arguments)
const productIDs = ['BTC-USD'];
const auth = { key, secret, passphrase };
const ob = new OrderBookSync({ productIDs, auth }); // order doesn't matter, no duplicate defaults

Perhaps, keyword arguments need to wait until a v2.0 release, BUT these are the kinds of considerations that make more-frequent releases more important, because they allow the community to keep up with rapid development and change. Allow for change and prepare for change, but don't hold too tightly to backwards compatibility forever.

Forwards compatibility is the more interesting and beneficial design paradigm.

[rmm5t]

Closing this out. I moved the checklist I was maintaining to a wiki page:
https://github.com/coinbase/gdax-node/wiki/Project-Roadmap