Introduce Adapter layer for YAML operations

[Tanmay-008]

Summary

Add an adapter layer to abstract YAML operations from the core logic. The adapter will act as an intermediary between the application and the YAML library, ensuring that library-specific changes or replacements do not impact the business logic.

Why This Is Needed

Library Independence — Decouple YAML parsing logic from direct dependency on any specific library.

Maintainability — Centralize YAML-related code, making upgrades or replacements easier.

Testability — Allow mocking or replacing the YAML layer during testing.

Clean Architecture — Follows the Adapter Pattern to keep logic isolated from external tools.

Expected Outcome

Core logic will no longer directly depend on YAML libraries.

Future changes in the YAML library will require modification only in the adapter layer.

Improved modularity, readability, and test coverage.

[Tanmay-008]

/assign

[brendandburns]

There's already a YAML abstraction in the loadYaml functions and the actual parsing is probably always going to be implementation dependent. So I don't think that this is a good thing to add to the client.

[Tanmay-008]

@brendandburns Could you please share your thoughts on PR #2660?I directly implemented the YAML handling layer.

[brendandburns]

If this is just about the ParseOptions object in that PR, then I think that's fine, I thought you were intending to add a wrapper on top of the yaml namespace.

[Tanmay-008]

Thanks for the clarification, @brendandburns. I understand your point — since the YAML abstraction already exists within the loadYaml functions, adding another layer isn't necessary. I’ll now focus on refining the YAML options part. Do you think it would be better for us to define our own YamlOptions type (as done in the PR)