refactor(link): expose config package

[gjermundgaraba]

Summary

• move Link config types, loading, validation, and YAML helpers into public link/config
• keep CLI flags/output and filesystem helpers outside the public config package
• replace duplicated E2E config types and serialization with link/config

Testing

• make build-link
• make lint
• go test ./... in link/
• make test-harness
• make test-e2e
• git diff --check

[greptile-apps]

Greptile Summary

The PR exposes Link configuration as a public package while preserving existing loading, validation, defaults, and YAML behavior.

• Moves configuration models, validation, helpers, and examples from link/internal/config to link/config.
• Keeps CLI flags, output, and filesystem operations in command or internal packages.
• Replaces E2E-only configuration representations with the shared public types and canonical YAML codec.
• Updates Link runtime consumers and tests to use the public package.

Confidence Score: 5/5

The PR appears safe to merge; no concrete changed-code failure remains.

The refactor preserves configuration defaults, validation, loading flags, path handling, and runtime consumption, while the E2E migration uses the same public model and canonical codec with updated serialization coverage.

Important Files Changed

Filename	Overview
link/config/config.go	Exposes the core configuration models, defaults, lookups, and comment collection with behavior preserved from the former internal package.
link/config/validate.go	Moves configuration and cross-reference validation into the public package without a substantive behavior change.
link/config/yaml.go	Publishes YAML loading and encoding APIs while retaining environment expansion, strict decoding, and optional validation.
link/config/relayer.go	Exposes relayer configuration types and lookup helpers with the existing pointer-based override semantics.
e2e/internal/harness/ibclink/relayer_config.go	Replaces duplicated harness serialization types with public Link configuration types while preserving generated values and defaults.
e2e/internal/harness/ibclink/attestor.go	Builds attestor workspace configuration through the shared public model and canonical YAML encoder.
e2e/internal/harness/ibclink/deploy.go	Migrates deployment configuration generation to the shared public configuration package.
link/cmd/ibc/config.go	Updates CLI configuration operations to the public loading API with equivalent validation and strict-field option mapping.
link/cmd/ibc/output.go	Keeps CLI-specific JSON, protobuf, YAML output, and file-writing behavior outside the public configuration package.
link/internal/fsutil/path.go	Extracts filesystem and key-path helpers from configuration code without changing their behavior.
e2e/go.mod	Reflects the public config package's existing YAML dependency in the E2E module graph without introducing a version upgrade.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  CLI[Link CLI] --> PublicConfig[link/config]
  Runtime[Link runtime services] --> PublicConfig
  E2E[E2E harness] --> PublicConfig
  PublicConfig --> Models[Config models and defaults]
  PublicConfig --> Validation[Validation]
  PublicConfig --> YAML[YAML loading and encoding]
  CLI --> CLIHelpers[CLI flags and output]
  CLIHelpers --> FSUtil[internal/fsutil]

Loading

_{Reviews (1): Last reviewed commit: "Merge origin/main into gjermund/expose-c..." | Re-trigger Greptile}

[dhfang]

Is this causing alot of friction for you in E2E development? I'm not super opposed to making this public - my main concern is that breaking changes seem likely as we continue development due to multiple reasons

• AutoRelayConfig is already changing as the design is being fleshed out.
• We want to simplify the relayer architecture and some configs currently reflect the way the relayer is designed. I could see DispatchPollInterval changing. We also want to expose parts of the relayer and attestors as libraries and make it possible to define custom implementations of some of the interfaces like ProofGenerator for example - I think the configs will need to change to support that as well.
• We've made a best guess at choosing configs that can be extended without breaking changes to support multiple light client types and multiple chain types. As we actually extend beyond just attestations and just EVM support we may find that we require breaking changes to support additional light client and chain types or there is a more ideal config structure.

Unless it's a huge inconvenience right now, I would consider waiting till we add QBFT LC support, auto-relay and finish defining the public interface for the relayer + attestor. Lmk what you think!

[dhfang]

I wouldn't want to make this public yet, not sure it's something we want to keep

[gjermundgaraba]

i understand, but technically we dont actually commit to it until we cut a release, and the config is mostly already a public api in the sense that it is what the user interacts with directly anyway. this is not critical though, just would make things slightly simpler to work with.

That said, if you prefer to just keep this as it is until more has landed, I'm not very opposed to it. Doesn't create a lot of friction (yet?), just having to make sure that things are kept in sync.