How to use latest version without deprecation warnings and explicit flags

Serverless Framework
1

When setting up a brand new project with the latest version of serverless, by default you’ll get a bunch of deprecation warnings about upcoming features that will become breaking changes; currently (v2.30.3) there are at least two that aren’t obvious to fix (by obvious I mean things like service not including a name property, that’s an easy fix). If you’re setting up a new project, you’re likely interested in using the new/upcoming features that will soon be breaking changes in order not to then have to deal with breaking changes on an existing code base, but it’s not very nice to have to declare explicit flags to enable coming features and to silent the deprecation warnings.

At the time of writing, my new project had to include this:

provider:
  ...
  apiGateway:
    # To hide warning https://www.serverless.com/framework/docs/deprecations/#AWS_API_GATEWAY_NAME_STARTING_WITH_SERVICE
    shouldStartNameWithService: true
  # To hide warning https://www.serverless.com/framework/docs/deprecations/#LAMBDA_HASHING_VERSION_V2
  lambdaHashingVersion: 20201221

When I start a new project, I wan’t it to be as clean as possible. :slight_smile: Actually I just held a session in my team to advocate for using serverless, but my “hey look how nice this tool is” kind of hello world example felt cluttered by noise like this. There were questions about what those obscure flags were, in an otherwise clean, minimal example project, and I just had to explain that “this is just boilerplate, ignore it”, but it kind of ruined my perfect clean example and gave my team members a sense of “this looks complicated”. :confused:

I also figured that NOT including the flags would render warnings during deployment, which would be equally frustrating - you don’t want to set up a new project with the latest version of a tool and get a lot of warnings, nor do you want to stick to behaviour that’s soon going to change and possibly cause backwards compatibiltiy issues.

Since these deprecations mention that the new behaviour will be breaking in the next major version, does this mean that we will have these warnings until you release serverless 3? But when’s that due?

What’s your advice on how to set up new projects without cluttering it with flags, and the same time not getting warnings during deployment?

I realize it’s hard to deal with this in a backwards and forward compatible way. But I was thinking whether it could be possible to have some command line option such as --emulate-v3, but if you end up making more breaking changes in, say, 2.4 or 2.7, an option that says “use all v3 features that are currently defined” might break things without control, so some sort of “level” of v3 features would probably be needed.

Or at least allow options or environment variables to “adapt to deprecations” without having to clutter the serverless.yml file. I know there’s a SLS_DEPRECATION_DISABLE= variable, but I don’t want to ignore the deprecation warnings, I want to “auto-fix” them. Could there be another variable to specify that, such as:

export SLS_DEPRECATION_ADAPT=LAMBDA_HASHING_VERSION_V2,AWS_API_GATEWAY_NAME_STARTING_WITH_SERVICE

Using that would have the same effect as declaring these two options in the serverless.yml file as shown above.

Thoughts?