Different version of modules for different environments
The single advantage to build a child module based on a public module is a case of wrapper, when we need to add some additional functionality to the existing public module.
But in case when public module already fit all our needs - is there any other considerations?
Can we define variable for a public module in a simple way like
variable "vpc" {
description = "VPC variables"
type = any
}
It will remove necessity to define all variables and describe their constraints - public module anyway already contains all variables and their constraints.
Iโm not quite sure what you are asking. A module is just a module, regardless of if it is available publicly or not. So you can use it anywhere - in the root module or in your own modules (both in a subdirectory of a root module or in a separate module only repository).
Make sure you check into the quality of any public modules. There are some excellent ones, but you might also find modules which have been created by someone years ago and abandoned.
We use a selection of public modules. Some are just used directly, but for some we wrap them inside our own custom module, which allows us to add business specific functionality/settings, reducing boilerplate code.
There isnโt any advantage in wrapping a third party module inside your own module if all you do is pass through all the variables & outputs. It is only advantageous if you do something else, such as hard code some of the values, add additional functionality, simplify the interface (by removing functionality or making business specific decisions about how the module can be used).