Protecting custom config names from future name-collision

[szabgab]

If I understand correctly the internal configuration parameters of Rocket and any custom configuration live in the same name-space. So if and when a new configuration parameter is added to Rocket it might collide with a custom parameter in a project, right?

If that's the case is there a recommended way to avoid it?

I guess prefixing my custom parameters with the name of the project would reduce the chances to almost 0, right?

[edgarogh]

Rocket uses figment to parse its config, and I'm pretty sure you don't really have a way to detect such collisions. It's also explicity mentioned in the source code that Rocket's native config "may grow in a non-breaking release".

If I were you and I was worried about collisions, I'd indeed prefix it. If you still don't want to do that, just be careful when you run cargo update and always check that the Config struct hasn't changed. You can also write unit/integration tests as a safety net.