Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow alloy fmt to show context #1255

Open
petewall opened this issue Jul 10, 2024 · 1 comment
Open

Allow alloy fmt to show context #1255

petewall opened this issue Jul 10, 2024 · 1 comment
Labels
enhancement New feature or request proposal A proposal for new functionality.

Comments

@petewall
Copy link
Contributor

Request

When using alloy fmt to validate a config and there is a syntax value, sometimes the line number is not helpful enough to find the issue. This is because many times the config is composed from many config files. Here's how it looks today:

% alloy fmt config.alloy
config.alloy:5:23: expected TERMINATOR, got IDENT
Error: encountered errors during formatting

It would be great if it would provide a few lines of context to help show where the issue is. Something like:

% alloy fmt config.alloy
    targets    = discovery.relabel.cadvisor.output
    scheme     = "https"
>  scrape_interval = 10s
    bearer_token_file = "/var/run/secrets/kubernetes.io/serviceaccount/token"
    tls_config {
config.alloy:5:23: expected TERMINATOR, got IDENT
Error: encountered errors during formatting

Use case

It would really help show where errors are, especially with composed configurations.

@petewall petewall added the enhancement New feature or request label Jul 10, 2024
@rfratto rfratto added the proposal A proposal for new functionality. label Jul 10, 2024
@rfratto
Copy link
Member

rfratto commented Jul 10, 2024

This is a good idea. I put it on our proposal queue because I think it needs some consideration for whether doing this by default might break existing editor integrations or make stderr harder to parse for tools.

Without putting more thought into whether a change could break things, my default stance would be to make this opt-in with a flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal A proposal for new functionality.
Projects
Status: Incoming
Development

No branches or pull requests

2 participants