For some reason, this was closed without an explanation or a workaround:
The question still stands unanswered – how do we import common configuration from outside of the service folder?
4 Likes
This has the same result as the OP in version 2.28.7. If this behavior is not allowed then it completely breaks the pattern for having shared configurations. This behavior began with 2.26.0:
`Serverless: Deprecation warning: Variables resolver reports following resolution errors:
- Cannot resolve variable at "custom.common": Cannot load file from outside of service folder,
- Cannot resolve variable at "custom.common": Cannot load file from outside of service folder,
- Cannot resolve variable at "custom.common": Cannot load file from outside of service folder,
- Cannot resolve variable at "custom.common": Cannot load file from outside of service folder
From a next major it we will be communicated with a thrown error.
Set "variablesResolutionMode: 20210219" in your service config, to adapt to this behavior now
More Info: https://www.serverless.com/framework/docs/deprecations/#NEW_VARIABLES_RESOLVER
`
1 Like
I’m glad others have reposted this, because I also retested last week on 2.28.6, after my original post was closed, hopeful that it was fixed. Alas it wasn’t, so I was puzzled why my post was closed without waiting for confirmation that it has indeed been fixed.
Hopefully it was a misunderstanding and the issue will be resolved soon; it should be pretty easy to recreate.
1 Like
I hope the issue will be resolved, I’m still seeing it in version 2.29.0. This functionality is pretty important to us.
Is it just a warning? The shared configs look like to be loaded correctly.
It does for now but the warning says the next major version will treat it as an error.
Hi,
same problem there,
this is very confusing, and if you look at the documentation about variables this is the example that is given…
Hi,
this will be a massive pain if you can’t use shared configs. We use a shared API Gateway, VPC, custom stage data that we share with 10+ services. We would have to duplicate these values in each service which would be a nightmare. I hope they are planning on providing an alternative method for managing config data like this.
2 Likes
Still an issue in 2.30.3
1 Like
Just ran into this as well. Per their deprecations, this will not be supported moving forward: https://www.serverless.com/framework/docs/deprecations/#serverless-constructor-configconfigurationpath-requirement
1 Like
I am hoping this is an unintentional deprecation message, as quite a common use case to import a file from outside the parent hierarchy.
It would be really appreciated if someone from Serverless themselves could investigate and respond, as my previous forum post looked like it was closed in error, but we haven’t heard anything in this thread.
2 Likes
Its a real worry for me too - I lean towards micro services and a level of shared config is very important…
All my projects since I started using serverless have this configuration. It just makes sense to use shared config when you’re dealing with micro services.
They are screwing a lot of people if the deprecation pushes through.
@garethmcc I’d appreciate if you could take a look at this thread and possibly provide some clarity for us as you closed the original forum post regarding this believing it was fixed, but we’re still seeing this deprecation warning.
So I wanted to understand more about whether this deprecation warning is intentional, or perhaps some over zealous logic flagging something that there is no intention to remove in 3.0, and in that case we do not need to be alarmed.
Thanks in advance.
1 Like
Here’s the github issue:
Multi-service repository support (aka Lerna)
I think we can relax a bit… for now. 
1 Like
The existing decision that they seem to still be going with is, to put it gently, very bad.
This breaks the model of a mono-repo with shared configs, and would stop large project migration to framework 3 without horrifyingly complex workarounds.
What is the appropriate level of stink to raise to get this decision backed off on or changed in detail? As it stands this just makes my world worse with no benefit.
One thing to bear in mind with any changes like this is that everything we do or propose to do is to help make serverless development as a whole better, safer, more secure, easier or any number of other possible reasons. We never make changes on a whim and sometimes the only way to get feedback from the community is to propose a change via deprecation notices.
We have tried surveys, questionnaires, interviews and a ton of other methods to try and get feedback from the community about where the framework should go to make decisions but none work better than putting something out there and getting actual feedback
1 Like
I haven’t tested this yet but I believe the workaround is to set the project directory property.
Restriction to not allow to (by default) reach outside of service folder, was made mainly for security reasons, to avoid errors and ensure best practices.
In a normal service scenario, you rather do not want to include files outside of service (or repository), as it makes the project not portable (cloning service on a different machine, won’t clone parent folders).
While in the case of multi-service repositories we advise to simply mark project boundary with projectDir, through which boundary can be relaxed to one of the parent folders.
If you still feel there’s some problem with that solution, please let us know, best if at Multi-service repository support (aka Lerna) · Issue #9095 · serverless/serverless · GitHub as it’s where we group all changes that are planned to be made to ensure solid multi-repository support
Hey everyone, after discussing internally here’s an update: the original deprecation (“Cannot load file from outside of service folder”) is being removed from Serverless Framework v2.
Including from parent directories (${file(../...) will work in v2 and v3 by default. The “projectDir” option will no longer be required (the “projectDir” option will actually be ignored).
2 Likes