Invalid nextflow.config parameters should be flagged (warning or error)

[davidparks21]

Flagging or erroring out when invalid parameters in nextflow.config exist would save debugging cycles.

I recently wrote an invalid nextflow.config parameter. I put the parameter in the wrong scope in one case, and in another case misnamed something, off by one character (hard to see, and 100% wrong).

Nextflow silently ignores invalid parameters in nextflow.config, but I suspect these kinds of errors cost a large percentage of users a substantial amount of debugging time (for me a week waiting on community forums for something that ended up being quite trivial).

At minimum, just a line such as this would have saved me:
(I had forgotten the aws.client scope)

WARN: Scope aws contains an unrecognized property endpoint.

That wouldn't break any existing workflows (if non-standard properties are used in some cases). Warnings could perhaps be ignored with a property. It would probably save a lot of users time configuring nextflow.

[bentsherman]

100% agree. The challenge is that the Nextflow configuration is just a map, and any code that uses the config just accesses whatever config options it needs at the time. This makes it easy to add new config options and keep the config definition decentralized, but on the other hand the overall config is never scanned for invalid settings.

In order to be able to detect invalid settings, we would need a way to define the config schema. We could define a central schema that must be updated every time a new config setting is added anywhere, but that would be cumbersome to maintain, and I don't know how you would even handle plugin config settings.

Ideally, we should be able to define the config schema in a decentralized way. Maybe classes like CondaConfig could implement an interface that allows them to define the set of valid options, with the idea being that CondaConfig is responsible for defining the schema of the conda scope.

[davidparks21]

Perhaps a standard way to specify the configuration options in the documentation and a build script that scans documentation to create a schema dynamically?

After all, if a new configuration option is added and not documented, a warning to the dev adding the feature might be a nice thing to see pre-release. If someone adds a feature and immediately starts seeing a warning, it'd be a gentle reminder to update documentation without getting in the way of development.

Even if some configuration options were needed and missed (I'm thinking some obscure legacy option), if a warning message started showing up as a regression, it wouldn't break anything and likely would end in a trivial documentation update.