sbt plugin

As described in https://gist.github.com/djspiewak/37a4ea0d7a5237144ec8b56a76ed080d

Then, once this is done, within the resulting project they should be able to run sbt deploy and immediately get a running, functioning HTTP lambda. Assume we have an AWS_API_KEY in an environment variable (or similar), presumably referenced in some way from the build.sbt.

I have an example of how to deploy an AWS lambda with SAM in https://github.com/christopherdavenport/js-test/tree/serverless.

Easy:

• Use @ChristopherDavenport's forward-thinking sbt-npm-package to prepare the .js and package.json
• Interact with SAM cli from sbt

Hard:

• Interact with the SAM YAML template. This seems to be a combination of:

  1. boilerplate our sbt plugin should provide, like the path to the generated JS, the name of the handler function
  2. config our sbt plugin could try and figure out, but hard to retrieve in practice: e.g. the type of event. These kinds of settings seem perfect for a g8 for various kinds of lambdas.
  3. any other custom user config

  Not sure what the best approach is. One option is to go full sbt-gh-actions and manage the template entirely from within sbt. Otherwise, will need some kind of hybrid approach.

Ideally we should have a plugin for both JVM lambdas and JS lambdas (or a hybrid plugin that can handle both) but let's focus on JS use-case for now since that's newer/more foreign to Scala folks. The nice thing is the SJS plugin can also adjust the Scala.js settings that tend to trip users up (namely, module configs).

Start with the linked gist, the serverless example repository, and the sbt-npm-package approach. Review how the SAM CLI and SAM YAML template would connect to build.sbt and Scala.js settings for the JS use case. Done would mean a project can run sbt deploy and obtain a functioning HTTP Lambda, with the template configuration approach decided.