Support for exported values from parent chart

[lucasoares]

Intellisense does not recognize Helm exports / import-values defaults

Summary

The Helm Intellisense VSCode plugin does not correctly resolve values imported through the Helm exports mechanism. When using a library chart that provides default values under an exports: block, Intellisense should treat these as part of the final .Values in the parent chart after import-values is applied, but currently it does not.

This results in missing autocompletion, false positives for unknown values, and broken IntelliSense when using templates that rely on merged values from exported defaults.

---

Use Case

I have a library chart that exports default values:

# common/values.yaml
exports:
  defaults:
    a: b
    c: d

My consuming chart imports those values using import-values:

# chart/Chart.yaml
dependencies:
  - name: common-implementation
    repository: file://../common
    version: 0.1.24
    import-values:
      - defaults

Then my templates reuse the library chart templates:

{{- template "common.autoscaler" . -}}

In the library templates I merge values like this:

{{- define "common.hpa" -}}
{{- $common := dict "Values" .Values.common -}}
{{- $noCommon := omit .Values "common" -}}
{{- $overrides := dict "Values" $noCommon -}}
{{- $noValues := omit . "Values" -}}
{{- with merge $noValues $overrides $common -}}
...
{{- end -}}
{{- end -}}

Because import-values brings exports.defaults into the parent chart's root .Values, I should be able to reference .Values.a or .Values.c. But the IntelliSense plugin currently reports these as unknown.

Note:
I know this is a very specific pattern, but it's one I've seen used in several charts over the years. I'm not sure whether Helm now provides a cleaner or more “official” way of handling this. These charts were created a long time ago, and migrating them now would be painful.

I could adopt a different pattern by only keeping defaults in the library chart, importing it with import-values using the child + parent syntax, and then manually merging everything inside the templates using deepCopy + merge into a $ctx variable. But I think this would lead to the same issue whene using the Intellisense extension.

Current pattern:

{{- define "common.hpa" -}}
{{- $common := dict "Values" .Values.common -}}
{{- $noCommon := omit .Values "common" -}}
{{- $overrides := dict "Values" $noCommon -}}
{{- $noValues := omit . "Values" -}}
{{- with merge $noValues $overrides $common -}}

Alternative pattern I would need to adopt:

{{- define "common.hpa" -}}
{{- $mergedValues := mergeOverwrite (deepCopy .Values.common) .Values -}}
{{- with merge (dict "Values" $mergedValues) . -}}

---

Expected Behavior

The plugin should:

• Parse the child chart's exports: block.
• Apply the import-values: rules declared in the parent chart.
• Treat the resulting values as part of the effective .Values used for IntelliSense. Make this configurable since not everyone using exports block do the merge thing.
• Provide correct completions and avoid false errors for keys coming from exported defaults.

---

Why This Matters

Many organizations use library charts to enforce consistency and DRY standards, especially by exporting default configuration bundles. Without IntelliSense support for this feature, large parts of templates appear broken in VSCode, reducing usability and causing confusion.

---

Reproduction Steps

1. Create a library chart with:

exports:
  defaults:
    key1: value1

2. Consume it in another chart:

dependencies:
  - name: lib
    import-values:
      - defaults

3. Reference an imported value in a template:

{{ .Values.key1 }}

4. IntelliSense doesn't recognize key1 as an value option.