Proposal: generate tool about cloudwego

[Skyenought]

Discussion:

1. For kitex, is it possible to ignore the "-module" parameter to generate files when the project has a go.mod file and is not in $GOPATH?

2. For kitex, can the -type in the code generation tool be determined automatically by the IDL file extension?

3. For hz and kitex both, they both belong to cloudwego, is it possible to use a unified set of tools to combine the functions of both?

4. For kitex, is it necessary to support custom templates ？

讨论:

1. 对于 kitex , 在项目拥有 go.mod 文件并且不在 $GOPATH 时，是否可以忽略 "-module" 参数来生成文件 ?
2. 对于 kitex , 代码生成工具中的 –type 是否可以通过 IDL 文件扩展名自动确定 ?
3. 对于 hz 和 kitex 来说两者同属于 cloudwego, 是否可以使用一套统一的工具来合并两者的功能 ?
4. 对于 kitex , 是否有必要支持自定义模板 ？

[ice4026]

3 反对, cloudwego 只是个 namespace, 未来一定还会有其他项目, 全部合在一起意义不大

[errocks]

3. 参考类似brew 跟brew cask 以及 tidb 的tiup , 我觉得挺好, 分久必合, 合久必分, 对用户来说应该是要一致的, 实现可以不一致, 至少语义是一致的. 用同一个规范; 用户都是懒的, 肯定喜欢方便的方案.
4. 第一阶段最好是有一个比较好的模板, 第二阶段再考虑要不要支持自定义

[godsoul]

3.支持，一个业务可以同时提供grpc和http两种服务

[lsjbd]

1 和 2 是不错的想法。 3 目前来说还没有必要，或者说，合并似乎不会有特别大的好处？毕竟合并后的维护成本也是要考虑的。 对于 4，上面 @errocks 的说法很好，应该先把当前的模板完善好，然后再考虑支持自定义。

[simon0-o]

1. -module 除了指定 module 名之外，还有个作用是表明你在 gomodule 模式下工作，如果在当前项目内含有 go.mod 时默认在 gomodule 模式下工作的话，可能会打破一些约定。尤其是对于 gomodule 项目来说，从当前路径往上，只要任意一个路径含有 go.mod 就可以被当作 gomodule 项目。
2. 最初没有通过后缀来判断的原因是，从我们内部实践来看，有相当一部分用户喜欢用一些奇奇怪怪的后缀，比如 .idl ，且 apache thrift 官方也没有对后缀做强制约束。这样做的话，同样是一个 break change。
3. 我补充一点是，正如 @errocks 所说，合久必分，分久必合，分分合合，增加的只有用户的迁移成本。
4. thriftgo 本身是支持插件的，如果有强烈的需求，可以通过实现 thriftgo 插件的形式去实现。

[lsjbd]

@Skyenought #590 已经支持通过文件拓展名推测 IDL 类型了。

[YangruiEmma]

结论同步：

1. 基于上面的讨论，-module 参数有一定的意义且修改会有不兼容问题，暂不做考虑
2. 已经在 v0.4.0 支持(Done)
3. 这个正在规划中(Doing)
4. 基于上面的讨论，暂时还不考虑