Closed wasabigeek closed 4 years ago
Let's also allow passing the token in the constructor for Server
in options
?
passing the token in the constructor for Server in options
~Stopped short of this~, some questions:
Slack
requires the config to be set globally), is that intentional? (Though fixing that should probably be a separate PR anyway)passing the token in the constructor for Server in options
~Stopped short of this~, some questions:
- were there any particular use cases you had in mind for letting each Server instance have it's own token? e.g. different slack bots running on the same server, but for the same team (since team would still be a global config, unless we do something there too)?
It's more of a best practice thing, we can have a singleton, but not globals where it's unnecessary. I don't have a better scenario, but for testing alone it's worth it IMHO.
- it seems like the token doesn't actually get used in Server (it gets passed down to Client, but Client doesn't use it, I suppose because
Slack
requires the config to be set globally), is that intentional? (Though fixing that should probably be a separate PR anyway)
We possibly have issues here, but I am not sure. The thing is that most people use this library with slack-ruby-bot-server, that doesn't use any of these globals and creates a bot instance with a token following an OAuth workflow. The globals were a facility to run a single bot for a single team with a token, which is deprecated by slack. Feel free to fix all/some/none! And greatly appreciate it and happy to help.
Fixes #240.
I assumed that setting the config in code would take precedence over an ENV variable.
Will do a separate PR for aliases after this!