Skip to content

lint: reintroduce ST1005 static check#3634

Draft
lbordowitz wants to merge 1 commit intoopentofu:mainfrom
lbordowitz:st1005
Draft

lint: reintroduce ST1005 static check#3634
lbordowitz wants to merge 1 commit intoopentofu:mainfrom
lbordowitz:st1005

Conversation

@lbordowitz
Copy link
Copy Markdown
Collaborator

This draft pull request for removing a linter static check exclusion is for demonstration purposes only.

For the sake of user friendliness, we capitalize some errors and add punctuation at the end as well. This chafes against ST1005, which is concerned with the composability of error messages. I will recommend a couple different paths:

  • Maintain the status quo: keep this linter disabled.
  • Adjust all error messages to conform to Golang best practices, and modify error messages as complete sentences when they reach a system/user interface.

I have my preference, but I'll keep it close to the vest for the sake of healthy conversation.

Signed-off-by: Larry Bordowitz <laurence.bordowitz@gmail.com>
@github-actions
Copy link
Copy Markdown

Reminder for the PR assignee: If this is a user-visible change, please update the changelog as part of the PR.

@yottta
Copy link
Copy Markdown
Contributor

yottta commented Jan 5, 2026

AFAICT, there are different paths for an error to be handled:

  1. Just wrapping by using fmt.Errorf("%w")
  2. By appending the error directly to the diagnostics by using tfdiags.Diagnostics.Append(err)

IMO, the first part shouldn't be that concerning because if an error bubbles up outside of a diagnostic context, we use Ui.Error() to print it.
To analyse and postprocess a chain of wrapped errors could end up to be a quite unreliable way of doing this.

I would focus more on the diagnostic side of things, where we can create a custom error type and use that to carry information for raw error rendering and for diagnostic rendering. For example, we might work something in here.
For now I would focus only on the errors that are reported by the linter.

Maybe there is already something similar for diagnostics, so I would be curious to hear from the other maintainers that has more knowledge on this side

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants