serverless: Invalid "--config" value: config cannot be nested in sub-directory

Same here as @jgeurts and @matthieudesprez, we use an internal generic Serverless as a component for all different applications.

For me it seems like a breaking change. Projects that use that pattern would be impossible to update to 2.2.0 and above.

Much like @matthieudesprez, our structure is a mono repo with multiple services and separate config files for each environment (production, review, etc) in each service directory:

sls deploy --config ./services/stack_a/production.yml
sls deploy --config ./services/stack_b/production.yml

or

sls deploy --config ./services/stack_a/review.yml
sls deploy --config ./services/stack_b/review.yml

The config files currently sit next to the lambdas they related to. Now having to move those config files to the root seems clunky. So now the root will be full of stack_a_production.yml, stack_a_review.yml, stack_b_production.yml, stack_b_review.yml, etc files, in addition to service folders those relate to. We’re on the relative small side but still have ~20 services and multiple environments.

@jgeurts thanks for explanation. Still in such case how to do you configure paths in service config, e.g. handlers for lambda?

I assume that e.g. for ./services/stack_a/serverless.yml service, if you keep lambdas configured in ./services/stack_a/ the handlers need to be referenced with full path to that directory, as below:

functions:
  function:
    handler: services/stack_a/path-to-handler.handler

Yep, the handler path is relative to the root of the project. Package excludes are also relative to the root of the project. Instead of preventing or deprecating the usage of a nested config, could there be a documentation note for others trying to use a nested config?

Thanks for the feedback!

As it’s affecting a lot of projects, tomorrow we will release a patch, that ensures Framework no longer crashes in such case, and behaves as before.

Instead we will issue a deprecation warning, to indicate we will bring strict handling with a new major release

I feel like I ran into issues with trying to deploy serverless from a sub directory rather than the project directory. Maybe plugins didn’t load correctly or dependencies weren’t bundled properly - I don’t remember anymore. I’ll give it another shot, though!

Yes, in that case all things that service depend on (like plugins and dependencies) also need to be installed into service directory. Service cannot rely on things in parent folders.

I feel like I ran into issues with trying to deploy serverless from a sub directory rather than the project directory. Maybe plugins didn’t load correctly or dependencies weren’t bundled properly - I don’t remember anymore. I’ll give it another shot, though!

If this change is purely from new user confusion when setting up a project, I would rather see the documentation be augmented rather than deprecate and disable nested configs. As I mentioned, we have ~20 services and its not hard to imagine others with much more. With nested configs being deprecated, I will now need to maintain 20 copies of package.json, typescript config, test config, and lint & style config files, rather than one.

@medikoo thanks for your quick reply.

The project that is currently facing the issue with the last release is a monorepo containing multiple stacks.

During our CI, we deploy them sequentially

sls deploy --config serverless/stack_a/serverless.yml
sls deploy --config serverless/stack_b/serverless.yml
...

If I understand correctly, we must now have our differents sls configurations at the root of the project ?

@matthieudesprez thanks for reporting.

Configurations by design should not be nested, as all paths in a config are always resolved against service directory.

It’s true we didn’t crash before on that, but it lead to unexpected config properties resolution behavior. Technically update you list helped in exposing an issue.