Catch errors earlier in development with the new Actions on Google linter
Today, we’re launching the Actions on Google linter for Node.js. The linter performs compile-time checks and alerts you when a webhook builds a response that doesn’t follow the documented requirements. Those include having too many chat bubbles (text responses), or lacking a response. This saves you time during development by ensuring that your code adheres to response building requirements — without needing to deploy and test your webhook.
Why use a linter?
As my colleague Leon mentioned in “Debugging Common Actions on Google Errors”, errors like
“MalformedResponse: <error details>” can come up frequently during testing.
Consider this code that implements a simple intent handler:
app.intent(‘my_intent’, (conv) => { conv.ask(‘first chat bubble’); conv.ask(‘second chat bubble’); conv.ask(‘third chat bubble’);});
It produces the following MalformedResponse error when a user triggers my_intent:
The simulator returns this error because there are three chat bubbles in the webhook response. Per the documented requirements, this constitutes a malformed response.
In general, I’d like to point out two things:
- Malformed response errors are common
- They are raised at runtime
Malformed response errors arise when responses don’t follow the requirements listed in the Actions on Google Responses documentation. The documentation lists the specifications for various types of responses (like Rich Response, Visual Selection Response, and more). As conversations get more complex, it becomes more likely to overlook a MalformedResponse error.
To help automate this process, you can use the Actions on Google linter. The linter scans your code for missed requirements based on the Responses documentation. This allows you to catch issues with your webhook before deployment. You can find a full list of support rules in actions-on-google-linter-nodejs on GitHub.
The linter is currently implemented as an ESLint plugin for Node.js developers, providing you with a familiar and consistent environment. It follows the standard patterns and architecture established in the ESLint community.
The linter produces the following output when checked against the code for my_intent:
$ ./node_modules/eslint/bin/eslint.js .4:3 error At most two simple responses are allowed actions-on-google/at-most-two-simple-responses
The linter gives us both the error and the line number of the failing code.
Distribution and installation
The linter is distributed via npm and the source code is available on GitHub. You can read through the installation instructions for how to set it up in your project. I encourage you to try the linter in your projects and submit pull requests to improve the rule coverage of the linter.
Linter details
Each rule works with an abstract syntax tree (AST) created by Espree, the default ESLint parser.
This tool processes the AST and identifies places where you make Actions on Google Node.js client library calls that correspond to building responses. Such nodes are roots of subtrees containing enough information to spot violations. Violations include which types of responses and in which order are being built.
To simplify the process of parsing client library calls, we also developed abstract functions that classify simple responses, helpers, and client library calls. Those functions are reused by the rules, and make it easier to create your own rules.
Thanks for reading! To share your thoughts or questions, join us on Reddit at r/GoogleAssistantDev.
Follow @ActionsOnGoogle on Twitter for more of our team’s updates, and tweet using #AoGDevs to share what your working on. Can’t wait to see what you build!
