JavaScript

[gr2m]

This evolution proposal is part of point 3 of the Hubot 3.0 milestone:

Modernize the project by translating CoffeeScript to JavaScript, improving integration with various developer tools, and adding features that make it easier for developers to automate their workflow.

Read the proposal 👀

Open todos / follow ups

• Update CONTRIBUTING.md, remove mention of CoffeeScript (CONTRIBUTING.md: remove references to CoffeeScript hubot#1349)
• Check in with Let middleware return a promise hubot#1338
• add an automated end-to-end test for hubot scripts written in CoffeeScript (end-to-end test for "yo hubot" hubot#1360)
• add tests for require('hubot/es2015.js') (add tests for require(hubot/es2015) hubot#1359)
• rename src/ to lib/ when everything else is done

[bkeepers]

Everything in hubotio/hubot#1327 should also be in this list, especially https://github.com/github/generator-hubot

[mose]

The author of decaffeinate uses hubot code base for his tests of achievement, it's worth citing https://github.com/decaffeinate/decaffeinate#status and the hubotio/hubot#1138 issue.

[gr2m]

good timing, I just found out about it and am looking into it right now. It looks like the better option for us. I’ll keep you posted

[mose]

Debian users that need modern node version have 2 main easy options:

• turning to nvm
• getting packages from nodesource

[gr2m]

good point, we could document these options as part of our breaking changes documentation / changelogs

[technicalpickles]

This is a great writeup, thanks for putting it together!

I have tons of questions and feedback 😁 It is mostly from experience with working on hubot, and also to make this specific enough that it can be implemented by someone that isn't @gr2m

[technicalpickles]

Could you link to this?

[technicalpickles]

Is the intent to do each of these as a PR per item? One big PRs? Some combination?

[technicalpickles]

s/trough/through/

[technicalpickles]

To be clear, this is improving internal readability, and is leaving the external API in-tact?

[gr2m]

correct

[technicalpickles]

😍

This sounds like a great way to build confidence in the conversion.

[tombell]

There is a with with duplication in that paragraph.

[technicalpickles]

Could we make sure to update (or create?) contributor documentation around using the linter? I've had times where I've started on new process, with CI running linter, and the feedback process is relatively slow until you actually start getting it running locally, if not as part of your editor setup.

[technicalpickles]

👍 from me for standard. I've only used it a couple times, but I like that it is zero config, and the style it encourages is pretty light on line-noise (ie no semi-colons).

[technicalpickles]

Is there a relevant link for this, ie tweet, documentation, etc?

[technicalpickles]

cc hubotio/hubot#1338 which is talking about adding it

[technicalpickles]

I really like this sentiment.

I'm not familiar enough with async/await yet, but would it possible to still take advantage of these support in the core? That is, can hubot users use it even if the core wasn't specifically written for it?

[gr2m]

Yes, Hubot user can take full advantage for the Node version they run their own Hubot instance in. If Hubot core adds Promise-based APIs then users which run their Hubot in Node 7.6+ can use async/await as these are sugar APIs to work with Promises. At the same time the core would continue to work with Node v4, so we don’t break Hubot instances that require this older Node version. Does that answer your question?

[gr2m]

I’m running into a bit of a blocker: when using the class keyword in the JavaScript version of Hubot, the way existing adapters inhert from Adapter would break because they are doing this

MyAdapter.__super__.constructor.apply(this, arguments);

which fails with TypeError: Class constructor Adapter cannot be invoked without 'new'. There is a related issue here. Slack also extends the Message class, probably others do so, too.

I’m still thinking about how to find the best balance between readable, easy to contribute/maintain code on the one and as few breaking changes on the other side.

Let me know if you have any thoughts on this :)

[technicalpickles]

which fails with TypeError: Class constructor Adapter cannot be invoked without 'new'. There is a related issue here. Slack also extends the Message class, probably others do so, too.

I did a search for this error (ie javascript class constructor cannot be invoked without new), and seeing it come up quite a bit. There's a lot of github issues around specific libraries/tools. I think http://raganwald.com/2014/07/09/javascript-constructor-problem.html looks like a decent description of the problem with some proposed solutions.

I’m still thinking about how to find the best balance between readable, easy to contribute/maintain code on the one and as few breaking changes on the other side.

Initially, I'd be most concerned with interoperability with existing code, unless we are committing to updating all the existing adapters as part of this work. I suspect less readable, harder to contribute to code can be confined to specific parts of the code base. Combine generous amounts of code comments about what it is trying to achieve, I think that is a good compromise.

That said, another approach is to figure out the most readable/maintainable thing, and then go back to add those bits to ensure better interop.

And one last thought: it should be possible to write tests cases that work on master, but fail in this case. That could help us know when the problem is fixed.

[gr2m]

I’ve to log off for today, just want to share what I’m looking into right now.

I haven’t fully tested it yet, but I think if we add sth like this to the footer before we return the classes that others inherit from, we should be fine:

const inherits = require('util').inherits
const EventEmitter = require('events').EventEmitter
class Adapter extends EventEmitter {
  // implementation of Adapter
}

function AdapterCompatibleWithCoffeeScript () {
  return new (Function.prototype.bind.apply(Adapter, [ null ].concat([].slice.call(arguments))))
}
inherits(AdapterCompatibleWithCoffeeScript, Adapter)

module.exports = AdapterCompatibleWithCoffeeScript

It’s not very pretty, but it might be a good compromise for the time being, so we can move forward with JavaScript implementation while remaining compatibility with existing adapters.

[technicalpickles]

@gr2m I just tried out npm install --save hubot@next on a bot I built last week, where I was using hubot-test-helper:

npm WARN unmet dependency /Users/technicalpickles/src/parrotbot/node_modules/hubot-test-helper requires hubot@'>= 2.6.0 < 3' but will load

I recall that there were some issues with hubot-test-helper related to inheritence and how it uses classes. I think this might be common enough of a module to make sure it works with hubot 3 & javascript.

[gr2m]

I’m removing hubot-test-helper right now from the yeoman script generator. We don’t use it in our scripts any more, the tests with it have been failing by default.

Do you have an app which is using it right now with passing tests?

[technicalpickles]

I don't, but could get it running in hubot-for-hubot pretty easily.

[gr2m]

from my experience, it’s better to keep tests less "magical" and more verbose. The hubot-test-helper is helpful when you setup test and you know exactly what you are doing, but for people new to the project they would need to check it out as well. The way we did it e.g. at https://github.com/hubotio/hubot-rules/blob/master/test/rules-test.js has more code, but also is clear simpler to follow for a new contributor, I think

[technicalpickles]

I think I missed that we were using the hubot-mock-adapter before now. I see hubotio/hubot-mock-adapter#7 that is being used there, and that https://www.npmjs.com/package/hubot-mock-adapter-v3 was released using that. Would you mind moving the fork of hubot-mock-adapter to the hubotio org?

There is documentation that recommends using hubot-test-helper, so we'll want to update that too: https://github.com/hubotio/hubot/blob/master/docs/scripting.md#testing-hubot-scripts

[technicalpickles]

@gr2m was asking for folks to test the new release. I just ran through it without any problem:

npm install -g generator-hubot@next
mkdir hubot-next
yo hubot
bin/hubot

I tested a few scripts I knew existed (ping, help, the rules), and they responded.

Only thing of note I saw was a message the first time launching bin/hubot that a package-lock.json was created and should be committed. That is going to happen for newer npm releases, but that is a general improvement for the generator, and not really specific to the Javascript evolution.

[gr2m]

Only thing of note I saw was a message the first time launching bin/hubot that a package-lock.json was created and should be committed. That is going to happen for newer npm releases, but that is a general improvement for the generator, and not really specific to the Javascript evolution.

This will be fixed once we remove the bin/hubot from the generator and replace it with a npm start which just runs the hubot binary provide by the hubot package

[joeyguerra]

Ping.

[gr2m]

I’m no longer working on Hubot I’m afraid. I cannot help I’m afraid

[joeyguerra]

Can I maintain it?