Allow service to be specified as object in serverless.yml

[HyperBrain]

What did you implement:

Closes #3513

How did you implement it:

If the parser encounters an object typed service property it sets service.service to the service name (retrieved from service.name). This is done for compatibility reasons because lots of plugins (core and 3rd party) use service.service directly to get the service name.
The object is stored into the service as service.serviceObject and all of its properties can be accessed with service.serviceObject.XXXXX.

In case the service property is a string, service.service is set to this and service.serviceObject is { name: XXXX }.

Additionally I added a service.getServiceName() method to provide an option for plugins to become more robust against changes in the serverless object structure and service.getServiceObject() that returns the object or objectified service definition.

How can we verify it:

Declare your service as object in the serverless.yml:

service:
  name: my-service
  foo: 1
  bar: doesnt-matter

Compatibility checks can be made with any existing serverless.yml that sets the property as string.

Todos:

• Write tests
• Write documentation
• Fix linting errors
• Make sure code coverage hasn't dropped
• Provide verification config / commands / resources
• Enable "Allow edits from maintainers" for this PR
• Update the messages below

Is this ready for review?: YES
Is it a breaking change?: NO

[HyperBrain]

I did not want to trigger another endless naming discussion 😈 . So I just named the service object property serviceObject because it describes what it is... threw away the idea of serviceAttributes because that would imply that there is an attributes declaration somewhere.

[nicka]

Ok, this is making me really happy 💃

I have a question, we're planning to migrate an sls v0.x stack to v1.x. BUT before we can do this we should be able to append an -r to the stack name (yeah I know, just create a new stack, the problem is that the stack contains an S3 bucket with 30TB).

Looking at the PR would the following be true?

service:
  name: foo-r

getStackName();
// "foo-r"

[nicka]

Ahh damn that would not be enough, the final stack name would become foo-r-dev 😢 . We need to be able to calculate foo-dev-r.

[pmuens]

Looking at the PR would the following be true?

@nicka yes, that's currently the plan.

Ahh damn that would not be enough, the final stack name would become foo-r-dev 😢 .

Hmm. That's bad. Maybe some plugin magic comes in handy here?

[nicka]

Once this is merged could we do?

service:
  name: foo
  stackName: ${self:service.name}-${opt:stage}-r

# OR

provider:
  stackName: ${self:service.name}-${opt:stage}-r

createStack() {
    const stackName = this.provider.naming.getStackName(); // Update this logic

[nicka]

Hmm. That's bad. Maybe some plugin magic comes in handy here?

Already tried this, but it's super embedded throughout the system.

We're currently running a forked version which does the following, ideally this get's refactored and uses a general way to overwrite stack names.

// Stack
  getStackName() {
    const name = `${this.provider.serverless.service.service}-${this.provider.getStage()}`;

    if (this.provider.serverless.service.provider.preV1Resources) {
      return `${name}-r`;
    }

    return name;
  },

[HyperBrain]

@nicka Agree that setting a custom stack name is a very valuable feature. But I think it is out of scope for this PR as it handles the possibility to specify the service as object.

I suggest opening an additional feature request "Allow setting a custom stackname" that can be implemented after this has been merged. It could specify that service.stackName can be used to set the value. Additionally the logic of getStackName() and any other hard-coded service name references should be replaced in the context of this new feature request.

/cc @eahefnawy @pmuens

[pmuens]

Nice! Just reviewed it @HyperBrain

Exactly what we need. Also big +1 for taking care of backwards compatibility 🥇

GTM