Having read some of the comments in #51 I am thinking that template specs needs a few tweaks to enable the most optimal dev flow
Example comments
Like this from @stuartko
Based on the hierarchy I see from the screenshots, this is by design if your linked templates are not within the directory of your master/main template or any of its subdirectories. For security reasons, we do not allow references to files in directories outside of your master template directory hierarchy.
& this from @snarkywolverine
@stuartko is correct that TemplateSpecs does not support this 'upward' hierarchy; it only works in a flat hierarchy (all templates in the same folder), or a nested hierarchy (where the 'entry point' / main template is in one directory, and the nested templates have child folder[s]).
Both point to a need for template specs to allow for a template to be able to traverse at least 1, but preferably 2 levels above the master template.
It would also be useful to be able to specify a full local path that is outside of the context of a repo, which for orgs that publish a core templates repo as an artefact and then use that in their development & deployment process then need to add extra steps to work around this current limitation.
Take a repo setup like this
To get all the templates you need you typically need to copy in templates that you have used in other projects (that aren't yet published as a template spec) & unnecessarily duplicate them between repos. This is fine for projects where you are working with people across multiple organisations but for internal use it's a bit naff. Of course the end goal is to get all your core templates available as template specs - but in the interim that adds frustration to the development cycle when you ideally should be able to reference to a file anywhere on your local disk when you are choosing to publish a template spec from an easily determinable file system path (like on build servers)
To sum up it would be great to allow any path to be used in the relative path, regardless of it being level to or below the current master template path, otherwise we need to add tooling around this which when compounded with #56 makes the development & deployment story for template specs less than ideal
Having read some of the comments in #51 I am thinking that template specs needs a few tweaks to enable the most optimal dev flow Example comments Like this from @stuartko
& this from @snarkywolverine
Both point to a need for template specs to allow for a template to be able to traverse at least 1, but preferably 2 levels above the master template. It would also be useful to be able to specify a full local path that is outside of the context of a repo, which for orgs that publish a core templates repo as an artefact and then use that in their development & deployment process then need to add extra steps to work around this current limitation.
Take a repo setup like this
To get all the templates you need you typically need to copy in templates that you have used in other projects (that aren't yet published as a template spec) & unnecessarily duplicate them between repos. This is fine for projects where you are working with people across multiple organisations but for internal use it's a bit naff. Of course the end goal is to get all your core templates available as template specs - but in the interim that adds frustration to the development cycle when you ideally should be able to reference to a file anywhere on your local disk when you are choosing to publish a template spec from an easily determinable file system path (like on build servers)
To sum up it would be great to allow any path to be used in the relative path, regardless of it being level to or below the current master template path, otherwise we need to add tooling around this which when compounded with #56 makes the development & deployment story for template specs less than ideal