These are some notes about intended use of tscfg, a sort of recommended use or "best practices" for your workflow.

First off, couple of general observations:

• tscfg is a code generator to be executed at some point prior to the proper compile phase of your application or library project. Some may see this as a limitation or drawback, others as a feature.

• Although perhaps obvious, the appropriate strategy for dealing with configuration properties greatly depends on your application and programming practices/preferences. YMMV.

The typical use of the tool involves the following aspects:

• The build-time aspect: that is, your configuration schema specification and the corresponding wrapper generated by tscfg. Typically (but certainly not required) a single **.spec.conf file is used for the specification as one often wants a single place as the "true" source of the configuration schema.

• The runtime aspect: that is, the concrete configuration, say myapp.conf, or multiple configurations, say myapp.dev.conf, myapp.prod.conf, to handle different environments, for example (along with the use of environment variables, system properties, etc.), with the actual values for the configuration attributes.

In a nutshell, a "best practice" is to capture the specification of your configuration schema in a separate resource, where all the (optional) "extended" type semantics supported by tscfg on top of the basic HOCON syntax can be used. Then, for runtime, just use regular Typesafe Config mechanisms as appropriate for your application or library for loading the concrete configuration from which to construct the instance of the tscfg-generated wrapper.