Ideas for the next big release

[runemadsen]

I think we should consider merging static and dynamic into a single tool that can deploy both static and dynamic infrastructure. Too many of our project require both, and it's a bit annoying to have two separate tools to deploy a single applications. Here's an idea of what it could be:

• CLI deploy - Deploys everything
• CLI deploy static - Deploys a static site to S3 and Cloudfront with all the current settings
• CLI deploy functions - Deploys all code in /functions to AWS Lambda just like Netlify
• CLI deploy function NAME - Deploys a single function
• CLI eject creates cloudformation templates for the static site and functions in a operations folder

Furthermore:

• You can write as many custom Cloudformation scripts in the /operations folder with or without the ejected templates
• The lambda build process uses Docker so we can support native plugins
• We should consider how to support something like a Docker-hosted app. Perhaps we have hooks that you can hook into before the deploy to run the Docker script? Maybe it just picks up any Dockerfile?

The aim should be that we can take any site that works in Netlify and it will also deploy with our tool with only slight changes.

[lucasdinonolte]

I like it and am all in on this!

Furthermore I'd like to add an idea that might be more of a "power user feature":

• Build Step Customization Hooks - allows users to inject their own code or pass a configuration to the webpack function build step (I had a webpack issue and could only resolve it by monkey-patching the webpack config inside of node_modules directly)

And some ideas to make getting started with this a bit simpler:

• More meaningful error messages- when setting things up and not being aware of the ESM <-> CJS conflict I got a "Validation Error" as error message, which made it a bit hard to track down that in reality it was a "File not found" error
• Simplify function config creation - maybe by adding more inline comments to the generated *.cf.js file that first time lambda user through the setting (or by extending the CLI prompt and then only give a user the config files when they choose to eject)

[lucasdinonolte]

Another idea that arose from the need of linking an existing subdomain to a site deployed using static. As this was just the subdomain of an already existing domain system moving the entire DNS to Route53 was not an option:

• Allow for configuration of external domains that don't go through Route53. The easiest way to do this is probably by "ejecting" the Cloudformation configuration and then let people edit things there.
  • If we see that this is a common use case we could also think about adding this to the CLI directly, so when setting up with an external domain you're asked if you want to go through Route53 or bring your own DNS