A setting that automatically sets -local from the module prefix is still a problem for anyone that works on some projects that use -local and some that don't. I would want there to be more demand before we considered adding it. I don't see how this would be a problem, we can add a flag named -auto-local or something like that and if that's used it just finds the local prefix from the module name and prepends it to the list of locals set by -local users would be in control, but this would allow people that want to use this functionality to have generic makefiles or IDE configuration that works consistently across their projects without special config...
4条答案
按热度按时间fcg9iug31#
请注意，goimports需要一个前缀。因此，如果您的包类似于
github.com/segevfiner/magicgopher,则需要将其设置为github.com/segevfiner。对于更复杂的情况，它实际上是一个逗号分隔的列表，因此对其进行设置仍然非常有用。老实说，goimports应该能够在仓库根目录中检测到配置文件(gopls也会支持),因此这样的设置可以在开发人员之间共享，而无需他们自己设置或依赖于特定的编辑器配置共享功能。brgchamk2#
我个人希望
-local从未被添加过。(@bradfitz 可能有自己的看法。)我并不特别想鼓励它的采用。我们肯定不会在没有更令人信服的理由的情况下创建一个goimports配置文件。对于任何使用
-local和不使用-local的项目的人来说，从模块前缀自动设置-local仍然是一个问题。在考虑添加它之前，我希望有更多的需求。bzzcjhmw3#
为什么人们不想鼓励
-local?这似乎是一个非常常见的模式，有3个分组。难道不能添加一些类似-local-mod的东西，使其等同于goimports -local $(go list -m)吗？ax6ht2ek4#
A setting that automatically sets -local from the module prefix is still a problem for anyone that works on some projects that use -local and some that don't. I would want there to be more demand before we considered adding it.
I don't see how this would be a problem, we can add a flag named
-auto-localor something like that and if that's used it just finds the local prefix from the module name and prepends it to the list of locals set by-localusers would be in control, but this would allow people that want to use this functionality to have generic makefiles or IDE configuration that works consistently across their projects without special config...