refactor(utils): simplify configuration validation and error handling - #4240
Open
KristjanESPERANTO wants to merge 4 commits into
Open
refactor(utils): simplify configuration validation and error handling#4240KristjanESPERANTO wants to merge 4 commits into
KristjanESPERANTO wants to merge 4 commits into
Conversation
KristjanESPERANTO
force-pushed
the
utils/refactor
branch
from
August 29, 2026 21:29
4fe7ca6 to
bd1b3b3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I ended up going down a bit of a rabbit hole with this PR. The main goal throughout was to make the code easier to understand and maintain. There are no intended changes to the normal application behavior. The error handling is also more consistent now, with error messages being passed to the point where they are handled instead of being logged in multiple places.
Please let me know if the PR has grown too large or if I have taken things in a direction that would be worth discussing 🙂
Commit 1
I started by looking at
checkConfigFileand felt that it was doing too many different things. I split its responsibilities into a few smaller functions to make the overall flow easier to follow.Outcome: clearer responsibilities and a simpler configuration validation flow.
Commit 2
While working on the file, I also noticed the arrow functions used for top-level functions. They are not wrong, but I find regular function declarations a bit more intuitive and easier to read in this context.
Outcome: a more consistent and readable function style, with the existing behavior preserved.
Commit 3
Finally, I noticed that some validation paths were throwing errors without any message:
An error without a message is not very helpful for debugging. This led me to move the error logging to the places where the errors are handled and to make sure that every
ConfigErrorcarries a useful message.Outcome: more consistent error handling and cleaner error output.
Commit 4
After looking at the remaining usages, I noticed that
getAvailableModulePositionswas only a thin wrapper around the internalmodulePositionsarray. It's not part of the documented API for third-party modules, so I removed it and letmoduleHasValidPositionusegetModulePositionsdirectly.Outcome: less indirection and a smaller internal API, without changing the intended behavior.