-
-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modernize directory structure and refactor chat adapters #186
Conversation
d803d7c
to
894b5a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work 👍
I would however use adapter
dir instead of messaging_handler
to keep all the custom Hubot adapters we support.
@armab Updated to use |
Move
scripts/stackstorm.js
andlib/
intosrc/
I created the
src/
directory and moved the code into it. This is done to separate the code from the repository "metadata" files, likepackage.json
and test files.Refactor chat provider adapters into their own modules
I broke up
post-data.js
andformat-data.js
into modules for their constituent chat providers. All of the provider-specific code is gathered up into one module, and all other modules are agnostic to the chat provider.Thanks to inheritance, this greatly simplifies all adapters, because now they all inherit from the
DefaultMessagingHandler
and only override the functions they need to. This is especially true for the Slack-like adapters (Mattermost, Cisco Spark, and Rocketchat), so much so that consolidating and simplifying them down further can be done in the future (once we have a test system for them).Breaking the adapters up should now also make it more obvious to casual users how to fix things for their provider adpater, and also how to create a new provider adapter from scratch. Hopefully this translates into more "drive by fixes".
Finally, because all of the adapters are broken up and simplified, we can (if we so choose) rewrite individual ones in coffeescript, which might be a bit more readable than Javascript and is reverse-compatible with Javascript. Rewriting them to use ES6 (along with
class
and "proper" inheritance with theextends
keywords) is also a possibility.Rename
tests/
totest/
It's a small change, but I moved the tests from being in
tests/
totest/
. This makesmocha
find the tests automatically.Update
CHANGELOG.rst
to use ReStructured Text syntaxWe have been surrounding words with single backticks to indicate fixed-width fonts, which is fine for Markdown files, but doesn't have the same effect for ReStructured Text files. Since the changelog is an RST file, I updated the syntax to be compliant with RST.
Additional Notes
I changed the comments on the copyright notice lines to single-line comments so that
gulp lint
passes properly. Previously it did not consider the notices when they were within multi-line comments.Coverage Differential
Test coverage went from:
to:
Note that the coverage Slack adapter decreased due to moving the Slack monkey patch out of its own module (used to be
lib/slack_monkey_patch.js
) into the chat provider constructor.Further Work
The Slack-like adapters can be simplified even further, primarily the Mattermost adapter since we will eventually have end-to-end tests with that.
Rewriting/refactoring the chat adapters individually with Coffeescript or ES6's
class
andextends
is also now possible and drastically easier to implement than before.Furthermore, the
src/stackstorm.js
module can still be simplified, similar to how #133 refactors it. This was not done yet because it did have as good of test coverage as the chat adapters, which would necessitate the need for more manual tests, or a lot more effort put into automated tests. However, if that refactoring is done properly, each function should be easier to test individually (eg: unit tests), instead of testing with integration tests (eg: mocking up an environment and/or HTTP responses and running the code singularly from thesrc/stackstorm.js
entrypoint) like we currently do. Ironically, this should hopefully end up reducing the overall amount of tests we need to write, which would also keep our test configuration simple (eg: do most/all of it with Travis tests), make our tests easier to write (unit tests vs. integration test), more reliable (no reliance on st2cicd for end-to-end tests), and faster (no need to run Travis tests and then kick off end-to-end tests on st2cicd).