Language Injection Support

[robspublic]

Background: When using Smithy to define API GW integrations that directly integrate with other AWS services, like DynamoDB, it is common to use Velocity Template Language (VTL) in the RequestTemplate and/or ResponseTemplate to do processing of the user input before passing on to the service, or processing of the service return before passing it back to the caller. Generally in coding, having language constructs (SQL, JSON, VTL) embedded in a string is a poor experience since the editor just treats it as a string, so you forego things like syntax highlighting and auto-complete. IntelliJ has functionality to overcome this with Language Injection so that it knows where processing from another language can be done within a file.

Request: It would be helpful if the Smithy Plugin provided support for Language Injection, see Language Injection SDK so that VTL syntax highlighting could be done for content within RequestTemplate and ResponseTemplate fields at least. AWS may allow VTL in additional locations, these are just the two that I am using right now.

[iancaffey]

Looked into this briefly, injection host logic isn't too crazy, but it is a decent bit of work.

At a high level, the language injection host (e.g. a string literal in a Smithy file) has to support decoding the host literal while keeping track of where every decoded character resides in the encoded string, so that way IntelliJ can properly format/highlight/etc. using the decoded string as input but then transposing that onto the original host literal in the editor window.

This gets complicated considering Smithy has a unique set of escaped characters (and the triple quoted strings/text blocks don't make this any easier), so I need to keep track of where the unescaped characters originally were for everything to work as expected for all types of string literals. If there are any bugs (e.g. if the round-trip logic doesn't produce an identical string), this causes immediate failures when IntelliJ tries doing the language injection. :/

The plugin has encoding/decoding logic already, but doesn't keep track of the index mapping. So would have to work through that.

I tested language injection on string literals without escaped characters and it worked perfectly fine (e.g. injecting regex for any @pattern trait values).