Checklist before moving to watson-developer-cloud

[germanattanasio]

• Add casperjs and test the basic interaction. See this example
• Add code coverage badge. I recommend https://codecov.io/
• Use eslint with 2 spaces indentation. Some of the variables are PascalCase and should be renamed to camelCase. Start with this config
• Add a CHANGELOG.md file
• JSdoc should be generated and updated on each commit using Travis. Every tag and branch should be documented. See http://watson-developer-cloud.github.io/node-sdk/ You can copy the process from here
• Since you are using Webpack, adding babel and es6 won't be a bad idea. Specially due to all the variables that could be constants.

Code review

• sdk.js:34: This whole section there needs some kind of clarification. The use of the regex seems suspect and both vars should be const.

• sdk.js:35: There is no test for this function and this function really needs a test.

• sdk.js:51: Should be const, not var

• sdk.js:97: function start has a required param of botID but the function never checks this id.

• sdk.js:136: there is more of this header stuff here. sending the request id as passed from a function like this makes me think their abstractions are pretty leaky. It would seem that generating a UUID and passing it as an identifier would be less good than simply hashing the payload or doing something else like that. and if it doesn’t matter, then some other method of generating that param should be in order. Ideally, this would be encapsulated at a different level than function by function.

• sdk.js:21: this is where the storage.js file is included. This file is very short. Has no tests. and seems to essentially replicate browser functionality If this is there to polyfill for node, it seems like there are better ways of managing this. as it stands, it look like it just adds complexity to the code without providing a whole lot. It would make more sense to me to have the storage object passed into the main SDK constructor and provide a default implementation or something. Or better yet, this storage should be refactored out of this completely unless there is a really compelling need to have it in there. It adds little value and is used all over the place. There also isn’t a way to substitute my own implementation if I wanted.

• Security notes: There is a comment in the file that the X-IBM-Client-Id should not be made public in a public environment, but then it doesn’t seem to offer any way of hiding it or hints how you might accomplish that.

• I’d defer to @nfriedly on this, but the onError function seems like a waste. The error handling semantics appears to be an artifact of the axios lib (probably an opportunity to switch to fetch). The onError function takes an error and rethrows it. If we're just rethrowing any error that comes in, I don't really see the point of including this in the catch block. This throwing of the error means the implementation needs to try/catch instead of dealing with appropriate http return values. This should be replaced with something that propagates the services errors in a cleaner way instead of re-throwing.The node sdk often has a callback with error args. that’s a lot easier to deal with IMHO.

CC: @nfriedly, @kognate

[ethanwinters]

@germanattanasio Regarding moving to Babel, we were forced to use Traceur by legal, because one of the child packages of Babel had the React Patents issue with it.

[germanattanasio]

Are you talking about https://twitter.com/jdan/status/765952442735398912 ?

[danwig52]

@germanattanasio German, React patents clause is by default verbotten in IBM products. We have an exception for the product itself, however both legal and the offering team did not want to potentially have IBM lead a client into a position where the FB patents clause could be used against them. They felt that put us in an awkward position legally. Because of this we removed any reference to pass our own AWSOM process (excluding our exception to use React internally)

[germanattanasio]

makes sense, thanks @danwig52 !