refactor: migrate away from Golang module github.com/vmware-labs/yaml-jsonpath by ErickdelaCruzCas · Pull Request #7527 · updatecli/updatecli

ErickdelaCruzCas · 2026-01-13T22:29:21Z

Context / Problem

While trying to use the maintained fork of yaml-jsonpath, Go’s module resolution and type system exposed two separate issues:

Module path mismatch at the dependency level

The maintained fork lives at github.com/helm-unittest/yaml-jsonpath, but its go.mod still declares:
module github.com/vmware-labs/yaml-jsonpath
If we try to require github.com/helm-unittest/yaml-jsonpath, Go fails with:
module declares its path as github.com/vmware-labs/yaml-jsonpath but was required as github.com/helm-unittest/yaml-jsonpath

YAML node type mismatch at compile time

The fork’s public API expects YAML nodes from go.yaml.in/yaml/v3.
Our code was constructing nodes using gopkg.in/yaml.v3.
Even though both packages represent “yaml.v3”, they are different import paths, therefore different Go types.
This breaks calls like yamlpath.Find(...) because *yaml.Node from one package is not assignable to *yaml.Node from the other.

Motivation

Prefer the maintained fork to avoid depending on an unmaintained upstream, while keeping our codebase buildable and type-safe.
Fix the module mismatch in the idiomatic Go way (without rewriting imports across the repo).
Ensure our YAML resource passes exactly the node types expected by the jsonpath library to avoid fragile adapters or unsafe conversions.

What changed (and why)

1) go.mod — use `replace` to redirect while keeping the declared module path

Added:
replace github.com/vmware-labs/yaml-jsonpath => github.com/helm-unittest/yaml-jsonpath v0.4.0

Why this is the correct fix

In Go modules, the declared module path in the dependency’s go.mod is authoritative.
Since the fork still declares itself as github.com/vmware-labs/yaml-jsonpath, we must keep the original module path in our dependency graph, and use replace to fetch the fork’s source at build time.
This avoids the “module declares its path as… but was required as…” error while still consuming the forked implementation.

Result

We continue importing github.com/vmware-labs/yaml-jsonpath/... (consistent with the declared module path).
The actual code used during builds comes from github.com/helm-unittest/[email protected].

2) pkg/plugins/resources/yaml/*.go — align YAML v3 package to match fork types

Files updated:

pkg/plugins/resources/yaml/condition.go
pkg/plugins/resources/yaml/source.go
pkg/plugins/resources/yaml/target_yamlpath.go

Change:

gopkg.in/yaml.v3 → go.yaml.in/yaml/v3

Why

yamlpath.Find (from the fork) expects nodes from go.yaml.in/yaml/v3.
Using gopkg.in/yaml.v3 produces identical-looking types, but Go treats them as unrelated.
Switching our import guarantees the YAML nodes we parse/unmarshal are the ones expected by the dependency, removing the compile-time mismatch cleanly.

3) go.sum — dependency graph normalization

Added checksums for the replace target (github.com/helm-unittest/yaml-jsonpath v0.4.0)
Removed checksums for old/unreferenced versions (e.g., github.com/vmware-labs/yaml-jsonpath v0.3.2) and other pruned transitive deps.

Why

go mod tidy updates the module graph and prunes unused entries so go.sum matches the effective dependency set.
It also selected github.com/sergi/go-diff v1.4.0 due to the fork’s transitive requirements.

Alternatives considered

Requiring the fork directly (require github.com/helm-unittest/yaml-jsonpath)
- Not possible due to the module path declared in the fork’s go.mod.
Forking again just to change the module line
- Works, but adds maintenance burden and moves us away from upstream updates.
Writing adapters to translate between YAML node types
- Would be brittle and unnecessary; type-alignment is the simplest and safest fix.

Risk / Compatibility notes

The YAML import change is scoped to the yaml resource implementation where we interact with yaml-jsonpath; it’s not a broad refactor across unrelated packages.
Using replace is explicit and documented to avoid “mystery dependency” surprises.

How to test

go test ./...
Specifically verify yaml resources still parse YAML and jsonpath queries behave as expected.

Footnote: This is my first contribution here. If anything in the style / structure / approach should be adjusted to match project conventions, happy to iterate — gentle reviews appreciated 🙂

ErickdelaCruzCas · 2026-01-16T16:28:06Z

Hi @olblak , have you had a chance to review this? Is there anything you don’t agree with?

olblak · 2026-01-16T20:59:32Z

@ErickdelaCruzCas thank your for the clear explanation, I think the replace approach is the only way to as you did

Your pull request looks great as I mentioned in the previous comment but I am wondering about the motivation for this snippet:

		urlPath, err := yamlpath_old.NewPath(y.spec.Key)
		urlPath1, err := yamlpath_new.NewPath(y.spec.Key)
		if urlPath != urlPath1 {
			fmt.Errorf("%s different from %s", urlPath, urlPath1)
		}

…m/ErickdelaCruzCas/updatecli into refactor--migrate-yaml-jasponpath

ErickdelaCruzCas · 2026-01-17T18:26:29Z

Thanks for calling this out.

That snippet was only there as a quick sanity-check while I was testing whether the two NewPath(...) implementations behaved the same (old vs fork) for the same y.spec.Key. The idea was to compare their parsing/normalization output during the transition.

Once I confirmed we don’t need to run both in parallel (because we’re switching the dependency via replace and aligning the YAML node types), that comparison became redundant — and I simply missed removing it before pushing. Sorry about that.

I’ll update the PR to remove the snippet (and any related leftover code) so we keep the change focused on the actual fixes: the module-path replace and the YAML v3 import alignment.

olblak · 2026-01-18T16:29:19Z

Thanks for calling this out.

That snippet was only there as a quick sanity-check while I was testing whether the two NewPath(...) implementations behaved the same (old vs fork) for the same y.spec.Key. The idea was to compare their parsing/normalization output during the transition.

Once I confirmed we don’t need to run both in parallel (because we’re switching the dependency via replace and aligning the YAML node types), that comparison became redundant — and I simply missed removing it before pushing. Sorry about that.

I’ll update the PR to remove the snippet (and any related leftover code) so we keep the change focused on the actual fixes: the module-path replace and the YAML v3 import alignment.

Thank you for the clarification, this makes sense at least that's how I understood it

ErickdelaCruzCas · 2026-01-19T13:04:44Z

fixed the compilation fail and tested again

Signed-off-by: Olblak <[email protected]>

ErickdelaCruzCas and others added 3 commits January 13, 2026 23:24

refactor: updated dependency

7ef951b

docs: delete notes

f5761d2

Merge branch 'main' into refactor--migrate-yaml-jasponpath

a5dc403

olblak added the dependencies Pull requests that update a dependency file label Jan 16, 2026

ErickdelaCruzCas added 2 commits January 17, 2026 19:23

feat: undo test

3b10dec

Merge branch 'refactor--migrate-yaml-jasponpath' of https://github.co…

bd92323

…m/ErickdelaCruzCas/updatecli into refactor--migrate-yaml-jasponpath

fix: remove in source

01ae0ab

Merge branch 'main' into refactor--migrate-yaml-jasponpath

228958f

olblak enabled auto-merge (squash) January 18, 2026 16:30

fix build

bf2bb7a

auto-merge was automatically disabled January 19, 2026 13:00
Head branch was pushed to by a user without write access

olblak and others added 4 commits January 20, 2026 21:00

Merge branch 'main' into refactor--migrate-yaml-jasponpath

3b5be81

Merge branch 'main' into refactor--migrate-yaml-jasponpath

bc1c242

Merge branch 'main' into refactor--migrate-yaml-jasponpath

049f98a

fix: revert regression

3f20f35

Signed-off-by: Olblak <[email protected]>

olblak enabled auto-merge (squash) January 21, 2026 20:02

olblak mentioned this pull request Jan 21, 2026

chore: migrate gopkg.in/yaml.v3 to go.yaml.in/yaml/v3 #7592

Merged

1 task

olblak merged commit fcda88f into updatecli:main Jan 21, 2026
5 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

refactor: migrate away from Golang module github.com/vmware-labs/yaml-jsonpath#7527

refactor: migrate away from Golang module github.com/vmware-labs/yaml-jsonpath#7527
olblak merged 12 commits intoupdatecli:mainfrom
ErickdelaCruzCas:refactor--migrate-yaml-jasponpath

ErickdelaCruzCas commented Jan 13, 2026

Uh oh!

ErickdelaCruzCas commented Jan 16, 2026

Uh oh!

olblak commented Jan 16, 2026

Uh oh!

ErickdelaCruzCas commented Jan 17, 2026

Uh oh!

olblak commented Jan 18, 2026

Uh oh!

ErickdelaCruzCas commented Jan 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ErickdelaCruzCas commented Jan 13, 2026

Context / Problem

Motivation

What changed (and why)

1) go.mod — use replace to redirect while keeping the declared module path

2) pkg/plugins/resources/yaml/*.go — align YAML v3 package to match fork types

3) go.sum — dependency graph normalization

Alternatives considered

Risk / Compatibility notes

How to test

Uh oh!

ErickdelaCruzCas commented Jan 16, 2026

Uh oh!

olblak commented Jan 16, 2026

Uh oh!

ErickdelaCruzCas commented Jan 17, 2026

Uh oh!

olblak commented Jan 18, 2026

Uh oh!

ErickdelaCruzCas commented Jan 19, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

1) go.mod — use `replace` to redirect while keeping the declared module path