If just adding the tags is unwanted, I can also look into adding general support for json configs. We would need to add UnmarshalJSON functions like the UnmarshalYAML functions.

thank you for sending this in, just tags are okay.

I am not sure if we want to add support for json configs, I don't see a big reason to add support for json configs.

thank you for sending this in, just tags are okay.

Perfect, thank you.

Just adding the json tags won't work as it also needs custom Unmarshal functions. As the json support is not wanted? I might close the PR and do the changes in my fork :/
(Currently still working on the custom Unmarshal functions. Once it is done I would open an PR and you can decide if you want it or not?)

also needs custom Unmarshal functions

we don't mind having the JSON Unmarshal functions, it would be useful to folks using Blackbox exporter as a library and build on top of Blackbox exporter like you are doing

What I meant was the full fledged support for configuring blackbox exporter via a json config file instead of YAML, in that side, will stick with YAML only.

First step is done with the custom Unmarshal functions. I might need to add some Marshal functions as well.
Can already tell that the current json lib is a pain as it does not support inline fields.

If wished I can also generate the json test cases during the test by converting the original yml test case to a json file.
Would remove the "duplicate" test data.

If wished I can also generate the json test cases during the test by converting the original yml test case to a json file.
Would remove the "duplicate" test data.

yes, that would be better then the duplicate config files.

As an additional question.
Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted. From what I know right now, there is no nice way to Marshal the config. To solve this we could make all the Modules pointers that would get omitted.

Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted.

I don't think we thought about this before, this might be the default. changing the way config is Marshaled would need a little more discussion.

if you want to change that marshaled, I would recommend creating an issue to discuss this with everyone, and if we agree on changing, i would prefer it to be it's own PR.