Version ranges for Hubot packages

[stephenyeargin]

I've got a handful of Hubot script packages and the recent (and a bit more frequent than expected) releases of major versions has caused a bit of trouble with keeping the peerDependencies bracketed.

For example, many legacy packages have:

  "peerDependencies": {
    "hubot": "^3 || ^4"
  }

Which causes this error when adding to a v7 instance:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: hubot@0.0.0
npm ERR! Found: hubot@7.0.0
npm ERR! node_modules/hubot
npm ERR!   hubot@"^7" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer hubot@"^3 || ^4" from hubot-redmine@1.1.0
npm ERR! node_modules/hubot-awesome-package-here
npm ERR!   hubot-awesome-package-here@"^1.1.0" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 

I don't really want to use legacy-peer-deps if I can avoid it.

I've adopted this as an approach:

  "peerDependencies": {
    "hubot": ">=2 <10 || 0.0.0-development"
  }

But at the current pace we may hit v10 by Christmas. 😄

[joeyguerra]

Is there something I can do to help?

Yes! I think v10 by Christmas is a good goal. Could be sooner though. I'll create an issue to post my thoughts on what v10 looks like.

[stephenyeargin]

Mainly want to see if there's guidance for package maintainers on an appropriate range for LTS. Rapid release are a great sign of the project's future, but it gives us a bit of heartburn to need make one-line changes to keep up. 😁

[joeyguerra]

Thank you for the feedback. I was trying to resuscitate development and I apologize for the churn. I'll work to stabilize the change.

I've been on a march to modernize the codebase - align and keep pace with Node LTS versions, load adapters from local disk/file, support org scoped adapters, .mjs script support, remove CoffeeScript support, and convert the API to async/await. I think I can add .mjs support to the v7 version. But removing CoffeeScript and moving to async/await style API will be breaking changes. I'll create an issue to start communicating/collaborating on that.

[xurizaemon]

@stephenyeargin you probably already spotted that this is a side effect of active development and the (re?) introduction of semantic-release

I wonder if there's something could be done to support hubot plugin maintainers so that a new Hubot release could trigger tests and an MR to bump the supported versions in the plugins

Roadmapping incoming updates and helping folks know what versions are coming down the pipeline would help too.

semantic-release will permit some workflow which doesn't result in a new major for each new feature, but as we're doing it (all credit to @joeyguerra for current pace), that is the current rate of version bumps

[technicalpickles]

Here's some historic context, in case it is helpful. In the past, I was extremely cautious with bumping the major version for this very reason 😅

When possible, I found it better to implement backwards compatible for changes, and having deprecation warnings/errors for when old ways are used. That way, you can choose the time to drop the deprecated changes, and make that a major version change.

It can make some changes a lot harder though.

[joeyguerra]

Here's the issue I created as a roadmap. #1658

[joeyguerra]

@stephenyeargin I have a PR with breaking changes (APIs are now async/await style). Is there anything I can do to help alleviate some heartburn when this PR gets merged?

[stephenyeargin]

@joeyguerra So every package I have works fine with the Shell adapter, but I can't get the Slack one to work with any version above v7, even with changing the --adapter flag to launch it.

[joeyguerra]

@stephenyeargin would it be possible to use the new hubot slack adapter? https://github.com/hubot-friends/hubot-slack

npm i @hubot-friends/hubot-slack

[stephenyeargin]

1. Looks like that's pinned to "hubot": "^7.x.x" in peerDependencies, so it complains when I try to install it on that branch.
2. Bypassing that, I get a complaint about the token in use. Guessing the adapter has a new setup process, but I couldn't track down docs for it.

{"level":30,"time":1693367566546,"pid":25715,"hostname":"Stephens-Mini.home.yearg.in","name":"Hubot","msg":"hubot-slack adapter v1.0.8"}
{"level":50,"time":1693367566547,"pid":25715,"hostname":"Stephens-Mini.home.yearg.in","name":"Hubot","msg":"Cannot load adapter [no path set] @hubot-friends/hubot-slack - Error: Must provide an App-Level Token when initializing a Socket Mode Client"}

[joeyguerra]

I'm updating the peer dependency to >= 7.0.0 and adding instructions to the README explaining how to configure the app with 2 tokens. One for the HTTP API calls and another for the SocketMode connections.

I also really appreciate you taking time to test these changes. I can't tell if anyone's using Hubot anymore;) Admittedly, it's old and there are other solutions to the "chat bot" problem.

[joeyguerra]

Readme has been updated: https://github.com/hubot-friends/hubot-slack

[joeyguerra]

@stephenyeargin I made a mistake with that last release. I forgot to include "BREAKING CHANGE" in the comments, which resulted in a minor version bump (8.1.0) instead of a major version (9.0.0). So async/await is now in the v8 version of Hubot.

As a consequence, v9 is going to include bumping the supported Node version (engine version) to v18. I just wanted to give you heads up on the upcoming change. I'm guessing it will result in a bunch of warning messages in the console about unsupported engine.