v5 Goals
Closed this issue · 8 comments
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;
axioshas presented some problems - Remove
return_responseparameter 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!
All right, good, guys. I can't wait for browser compatibility improvements!
@npacucci Definitely. Feel free to let us know if you have any suggestions as well!
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.
For all interested, the first release candidate has been published - v5 Release Candidate 1
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!
🎉 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
@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!