<p>I have several apps of different shapes and purposes, each with their own <code>templates/</code> folder as generated by <code>helm create chart</code>.  The templates within each App are sufficiently different to justify having them as one-offs.  However, the <code>_helpers.tpl</code> is identical for all of them.  I'd like to externalize/reuse this <code>_helpers.tpl</code> template so that I don't need a copy of it in every app.</p>
<p>What I have currently looks something like this:</p>
<pre><code>App1
|--app (random source code crap, irrelevant)
|--chart
|---templates
|------_helpers.tpl
|------ deployment.yaml
|------ other unique templates

App2
|--app (random source code crap, irrelevant)
|--chart
|---templates
|------_helpers.tpl
|------ deployment.yaml
|------ other unique templates
</code></pre>
<p>I'd like to centralize this <code>_helpers.tpl</code> so that I don't need to maintain N versions of it.  I'm imagining something like this, but I'm open to whatever:</p>
<pre><code>Common
|--chart
|----templates
|------ _helpers.tpl (I live here now and was removed from the 2 Apps below)

App1
|-- app (random source code crap, irrelevant)
|-- chart
|--- templates
|------ deployment.yaml
|------ other unique templates

App2
|-- app (random source code crap, irrelevant)
|-- chart
|--- templates
|------ deployment.yaml
|------ other unique templates
</code></pre>
<p>I have tried doing this with a symlink pointing <code>AppN/chart/templates/_helper.tpl</code> to <code>Common/chart/templates/_helper.tpl</code> but that's clearly bad and I imagine there's a built-in way to do this that I'm just not finding.</p>
<p>Even if <code>AppN/chart/templates/_helpers.tpl</code> needs to exist only to read <code>../../_helpers.tpl</code>, that's good enough but I'm not sure how to approach that given the YAML-y/Go-y syntax.</p>

oooyaya
<p>If one Helm chart includes another as a subchart, any <code>{{ define }}</code> templates anywhere in any of the parent or child charts are visible to all of the charts to be <code>{{ include }}</code>d or <code>{{ template }}</code>d.  This means that you can create a <a href="https://docs.helm.sh/docs/topics/library_charts/" rel="nofollow noreferrer">library chart</a> that only contains the helpers, with basically exactly the structure you show above</p>
<pre class="lang-none prettyprint-override"><code>common
+-- Chart.yaml
\-- templates/
  +-- _a_helper.tpl
  \-- _another.tpl
</code></pre>
<p>This looks like a normal Helm chart in that it has a <code>Chart.yaml</code> file and a <code>templates</code> subdirectory, but inside <code>templates</code> are only <code>_*.tpl</code> files and not <code>*.yaml</code> files, and those files only contain <code>{{ define }}</code> top-level directives.</p>
<p>In your application charts, you can consume the library chart like any other chart dependency.  If these are all checked into the same repository, you can use relative <code>file:</code> URLs to point at the common chart.</p>
<pre class="lang-yaml prettyprint-override"><code># app1/Chart.yaml
dependencies:
  - name: common
    repository: file://../common/
</code></pre>
<p>You do need to remember to run <code>helm dep up</code> before deploying the application chart; this makes a copy in the <code>charts</code> subdirectory.</p>
<p>(If you're using modern Helm 3, you can flag the library chart with <code>type: library</code> in the <code>Chart.yaml</code> file.  If you're using obsolete Helm 2, the dependency needs to go in a separate <code>requirements.yaml</code> file.  You can't usefully configure the library chart with values; if an application chart calls <code>{{ include &quot;common.some.template&quot; . }}</code> it will pass along the parent chart's view of <code>.Values</code> as part of the template parameter.)</p>
