skellington-closet / skellington Goto Github PK

Right now Skellington and botkit configs are mixed together in the same flattened config structure. I think we should break out the botkit specific configs into their own stanza, something like:

{
  "slackToken": "xob-abc-123",
  "plugins": [...],
  "botkit": {
    //botkit specific configs go here
  }
}

This will simplify the logic of passing configs to botkit and prevents collisions from future config options. It leaves the door open for different implementations in the future.

@jasonrhodes had a thought to make the key dynamic using a botType option:

{
  "botType": "botkit", // default to botkit
  "botkit": { ... botkit configs ... }
}

This will make it easy to switch config types in the future and support different underlying implementations.

Something to consider: whatever the underlying implementation it would be great to make sure the plugin API stays in tact. Not sure that's possible if we switch out the underlying implementation. We will probably need an adapter layer... but that's a discussion for another day.

This doesn't seem to work, as it doesn't appear you are passing all config from the skellington constructor into the botkit constructor

The devDependency proxyquire was updated from 2.1.2 to 2.1.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

proxyquire is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Keep deps up to date with greenkeeper. Do a patch bump when dependencies change. Merge in dev-deps when they change, but don't change skellington version.

Skellington adds an rtm_close listener to reconnect to the RTM session if there was an error. This is problematic for two reasons:

1. Sometimes the RTM session can be closed intentionally and we are not checking for that
2. Botkit has it's own reconnection strategy, this causes the RTM connection to be re-established twice, resulting in double messages/responses.

We should remove the rtm_close handler and defer the reconnection to Botkit.

Use something like skellington-logger to distinguish between botkit logs and skellington logs and to print a better format.

The dependency botkit was updated from 0.6.18 to 0.6.19.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

botkit is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

On debug, log out each message to hears callbacks (maybe the on callback?) and allow configurable log formatter.

Attach "interesting" debug information to the message (i.e., the calling file to track down a weird plugin).

debug = true at the skellington level, should set debug = true at the botkit level, unless there is an explicit override for botkit = false.

Now that greenkeeper is wired up, it would be great to have some integration tests to protect against breaking changes in the interface of a dep.

One possible strategy would be to have a staging environment and use the Slack API to post messages. We could have a test "echo" plugin that just echos back what it hears in a channel. We could then inspect channel history to ensure the plugins connected successfully and was able to post.

I'm not sure how to integration test inviting a bot to a team, I'm not sure there is an API for that.

From the Botkit docs:

Note: If you are not also establishing an RTM connection, you will need to manually run the controller.startTicking() method for conversations to work properly.

We need to call controller.startTicking if we are not establishing an RTM connection.

This is useful when wanting to build a horizontally scalable Slack App. Conversations are still stateful though, so that will continue to be an issue. But sometimes you just don't want an RTM connection, ya know?

It would be great to support other engines. The first I'd like to look at is Slapp.

There are a lot of details to flesh out, and this would most certainly be a major release. This ticket is a placeholder, more details to come.

What would be ideal is for Skellington to have it's own Engine interface and then we could write different engine modules (e.g., skellington-engine-botkit, skellington-engine-slapp). This would keep Skellington from growing unwieldy and also allow others to write their own engines if they want. This may be a pie in the sky dream... but 🤞

I think the plugin API should support a "type" or "engine" field. If absent, it will default to "botkit" for backwards compatibility. Plugins whose type doesn't match the engine will not be loaded and an error should be logged.

Maybe something like botkitSpawn in the config?

Botkit is a critical dependency of Skellington. I have two competing concerns: one that skellington remain stable and two that users not have to wait for new features in Botkit.

I've locked down the Botkit version because of the first concern. But I've also hooked up greenkeeper to this repo to address the second.

This approach definitely favors stability. However the drawback is that a new version of Botkit will require a new version of Skellington. This seems like it will create unnecessary work all around.

I'm thinking "betting on semver" and changing to a ^ match on the Botkit dep. ^ matches will allow propagate new features and prevent breaking changes from being pulled in. Botkit is currently in 0.X.X version, so caret match will pick up "patch" changes only (which are equivalent to minor version bumps of a 1.0.0 or greater package). So far, I believe Botkit has followed semver well. If it looks like they don't follow it, I will go back to a locked version.

To satisfy my want for stability, I'll document how to lock down deps (shrinkwrap) and how to lock in a specific version of botkit in case of a breaking change (roughly cd node_modules/skellington && npm install -S botkit@version && cd - && npm shrinkwrap)

Update Travis, Coveralls integrations and buttons to reflect new org. Update links in changelog and readme.

Hosting bots on AWS Lambda + API Gateway is the current hotness, but I really like a lot of your framework's tooling.

Do you have advice or perhaps examples of configuring the code to work via various AWS Lambda invocations?

Ref:
https://aws.amazon.com/blogs/aws/new-slack-integration-blueprints-for-aws-lambda/
https://aws.amazon.com/blogs/compute/create-and-deploy-a-chat-bot-to-aws-lambda-in-five-minutes/

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

No reason to reinvent the wheel here...

Also make sure to remove any deps associated with express.

The devDependency coveralls was updated from 3.0.7 to 3.0.8.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

coveralls is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Need to start a changelog, at least starting in 1.0.

Look into ways to automate this using commit history.

The devDependency sinon-chai was updated from 3.3.0 to 3.4.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

sinon-chai is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The 200 and 500 OAuth flow just return JSON. Users should be able to define a success redirect and failure redirect in config.

I've observed this on single-team bots, but I'm sure this would affect Slack apps as well. After some time, the RTM connection times out, I believe because the pong response doesn't come back after a timeout. This is the error logged:

Error: Stale RTM connection, closing RTM
    at Timeout.pinger [as _onTimeout] (/Users/cfurfarostrode/src/projects/pizza-bot/node_modules/botkit/lib/Slackbot_worker.js:182:35)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)

It would be good to catch that error and try to reconnect. If we can't reconnect, exit (if single team bot and option is set) or at the very least log something out in the logs. It would be good to include any team information we have, though we might not have any in that error.

It's about that time... maybe something like this?

lib/singleBot (sets up a single team bot)
lib/slackApp (sets up a slack app)
lib/config (manages config)
lib/help (registers help listeners)
lib/server (starts webserver, etc)
lib/lifecycle (initializes plugins, botConnected)

Currently this is setup to use a Slack Token and connect to one team. Are there any plans to support multiple teams?

Need to make the startRTM callback an errback style callback. Exiting for a single team bot makes sense: there is nothing for the app to do. But for a slack app, this is pretty bad and makes skellington fragile.

Version 2.4.0 of sinon just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As sinon is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴