[PoC] Parse exported script options with lib.TestPreInitState
access
#3000
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.
This is built on top of #2999 and is a PoC of how we can parse exported script
options
while we have access to the*lib.TestPreInitState
.Because of the changes in #2999, JavaScript modules also have access to the
*lib.TestPreInitState
, so it can be used as a central place to coordinate things. For example, JS modules could presumably "register" scenario options specific to them, which could then be used when parsing and validating the options.This is not intended for merging as it is, even though it slightly improves the UX (multiple errors when parsing the script options can now be returned at the same time), it's just a PoC that could be used for discussion. There are plenty of unresolved issues with it! For example, it doesn't handle .json config files or options that are in a .tar archive's
metadata.json
file. Both of these could presumably be made to work in a similar way, since we have the*lib.TestPreInitState
in both cases, but it would require further refactoring.The important part of this PoC is being able to statefully parse JSON files, having access to some k6-specific context while we do it, without fully rewriting the whole config. That said, the complexity overheads are somewhat big, so I am not sure if this is the way we want to go ahead in resolving #883, probably not... 😞