Skip to content

v5 Goals #897

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

Closed
9 of 13 tasks
dpopp07 opened this issue Jun 12, 2019 · 8 comments
Closed
9 of 13 tasks

v5 Goals #897

dpopp07 opened this issue Jun 12, 2019 · 8 comments
Labels
Request for comments v5 Issues that will be solved when major version 5 is released

Comments

@dpopp07
Copy link
Contributor

dpopp07 commented Jun 12, 2019

Schedule

We plan to release v5 in September 2019. This issue will be updated with more specifics on timing and the availability of release candidates as we get closer to that time.

8/30/19: Release Candidate 1

Breaking Changes

  • Change how we export types Seeking community feedback
  • Find a new request library; axios has presented some problems
  • Remove return_response parameter and always return the detailed response (896)
  • Pass the detailed response as the first argument when using callbacks
  • Remove support for Node versions 6 (EOLed in April) and 8 (will EOL in December)
  • Use lower-camel-case parameter names to match typical JS style convention
  • Decouple authentication mechanism from service constructor
  • Remove location of direct export of the IAM Token Manager to be with the new Authenticators
  • Add types to all Promise return values

Non-breaking major changes

  • Add type definitions for WebSocket methods (764)
  • Improve browser compatibility
  • Use only TypeDoc for generated documentation
  • Services can be loaded independently using webpack

This issue will be used to track features and changes we want to make in the next major release of this package. We welcome community feedback on these goals - do people want these things? Are there other implementations/packages we should be looking at? Any comments are appreciated!

@dpopp07 dpopp07 added Request for comments v5 Issues that will be solved when major version 5 is released labels Jun 12, 2019
@npacucci
Copy link

npacucci commented Jun 14, 2019

All right, good, guys. I can't wait for browser compatibility improvements!

@dpopp07
Copy link
Contributor Author

dpopp07 commented Jun 14, 2019

@npacucci Definitely. Feel free to let us know if you have any suggestions as well!

@MasterOdin
Copy link
Contributor

MasterOdin commented Jul 13, 2019

Directed here from #908 about the typing which would be beneficial to address as it causes CI failures for stuff like #910 which attempts to follow current practices.

In a Typescript only world, I'd suggest dropping the namespace bit and just export everything from the top level with a export default on the single class. One would then be able to do (for example) import AuthorizationV1, {Options} from 'ibm-watson/authorization/v1'. However, this makes it so that people using Node (and other CommonJS based importers) use const AuthorizationV1 = require('ibm-watson/authorization/v1').default. Similarly, if you just did a normal class export, then NodeJS people would have to do const AuthorizationV1 = require('ibm-watson/authorization/v1').AuthorizationV1 or const { AuthorizationV1 } = require('ibm-watson/authorization/v1'). Both of these feel inelegant, specially as the former feels confusing for people who only use node and the latter weird in that there's only really one thing being exported that they can use. Personally, for my own work, whenever I've had files where it's one class export and then interfaces and such, I've split it into two files, one with just the class, and then the other with the types. For the above example, this would mean having ibm-watson/authorization/v1 and ibm-watson/authorization/types for example.

You could also look into babel for CommonJS transpiling where instead of writing default exports as module.exports.default = AuthorizationV1, it would write it as module.exports = AuthorizationV1, though I've never really explored this and have no idea how this works in practice with also generating type files.

@dpopp07
Copy link
Contributor Author

dpopp07 commented Aug 30, 2019

For all interested, the first release candidate has been published - v5 Release Candidate 1

@dpopp07
Copy link
Contributor Author

dpopp07 commented Sep 19, 2019

Note to anyone contributing to the release-candidate-v5, I've rebased the latest changes from master into a new branch that I'll be using for further major release work named release-v5-rc-2. Please direct any inflight changes towards this branch. Apologies for any inconvenience!

@MasterOdin

@dpopp07
Copy link
Contributor Author

dpopp07 commented Oct 4, 2019

🎉 v5.0.0 gas officially been released! 🎉

Most of the goals were completed with some notable new features:

  • A new, stable, and flexible way of authenticating
  • Improved typing across the entire library for TS users
  • Parameter names changing to match standard JS conventions
  • Improvements to allow for use in the browser without workarounds

@dpopp07
Copy link
Contributor Author

dpopp07 commented Oct 4, 2019

@npacucci Give this latest release a try in Angular and confirm if it is working or not. We have it working here but I wanted to check with you to make sure. Thanks!

@dpopp07 dpopp07 closed this as completed Oct 4, 2019
@npacucci
Copy link

Hey @dpopp07 I'm using the 5.1.0 version now.

I hope my feedback can help you to improve the SDK. Thank you!

@germanattanasio germanattanasio unpinned this issue Dec 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request for comments v5 Issues that will be solved when major version 5 is released
Development

No branches or pull requests

3 participants