Thanks @cedricroc for this PR! It could indeed be convenient to be able to expose more parameters on the client-side.

For consistency, I think that the config parameters in config.yml should have the same type as the command-line parameters they stand for (see vroom usage).

So threads and explore could be integers in config.yml. Then if override is true, we'd check for input values to replace the defaults (that's just a matter of simplifying the new checks in index.js).

Another benefit of this approach would be that people that don't want to expose those parameters on the client-side would now have a simple way to change the defaults right from the config.

Hi @jcoupey,
I update with your comment. Thread and exploration options are fixed by default value in vroom-backend.
What do you think of this version ?

I've not seen replace default value. I corrected

Thanks @cedricroc for the changes and submitting this PR!

I've done a couple minor adjustements:

• in the merge commit, reorder options in src/config.js to silence es-lint warnings
• in f19b3a0, remove the uncessary req.body.options.t and req.body.options.x checks. This was causing the check to be false when passing "x": 0 so -x 5 was still sent in the options.