Improve options exporting in HAR conversion and to JS runtime #713
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.
After merging #681, I realized that my advice to @MohanPrasathS there to use something like
rt.Set("options", runner.GetOptions())
probably wasn't the best idea... The main reason for that was very similar to the reason I recently had to do this hack in for the options injection in the HAR file conversion. Basically, directly exporting the null-able types inlib.Options
to JSON produces a lot ofnull
and empty array/object values. Another slight drawback is that if a user adds their own non-k6 keys in theoptions
object, they would have been overwritten and lost.This PR adds a new method to
lib.Options
that allows us to flexibly traverse thelib.Options
fields that are set. This improves both the HAR export format (it now uses unquoted JS keys) and the options propagation back to the JS runtime (no extra nulls and non-k6 user-defined options there won't be overwritten).It's still not perfect... The current output of simply running script like this without any extra parameters:
would be something like this:
iterations
andmyOption
are fine,tlsVersion
appears due to this bug andsystemTags
is included due to a limitation in the way we (don't) track and handle complex default values...Also, both this and in the original fix for #613 won't properly work when executing the script in the cloud (especially when there are multiple k6 instances), but fixing that would probably have to wait until we have proper cluster execution in k6 itself...