sublime-build
sublime-build copied to clipboard
golang
Support for "go fmt"
Hi,
I miss the option of firing fmt with every build. It is planned to support this?
Cheers, JP
@wbond Maybe this should be a separate sublime-fmt (golang-fmt) plugin that does gofmt, goimports, or goreturns?
It already is a part of GoSublime. Is sublime-build meant to complement or replace GoSublime?
I think it's intended to be an alternative/replacement. Mind you, GoSublime could also rely on sublime-build and sublime-config instead of doing everything itself.
Yes, Golang Build is meant to be part of a "modular" alternative to GoSublime. Rather than a single package, the idea is to split different functionality into different pieces so they can be developed more easily without needing centralized coordination.
The golangconfig dependency this package uses was built to make it easy to build other Go packages without having to get into the gory details to detecting the user's Go environment properly, or users having to edit multiple settings in order for different packages to know about the Go environment.
Also, this package is an alternative approach to a build system than GoSublime. The GoSublime build system open a panel at the bottom of the screen and have to type into a faked-terminal to run commands. This package integrates with the Sublime Text build system, allows for variants to be triggered via the command palette, etc.
I personally would expect a gofmt package to be separate. I would expect it to offer a format on save option, plus a command palette entry to support formatting at any point. I've been thinking about whipping one up myself for my own use.
Format on save is the default in GoSublime, which makes more sense to me than opt-in, especially if the user is installing the golang-format package.
Are there plans to have a Go meta package that depends on various other little packages? Maybe it could also integrate https://github.com/alecthomas/SublimeLinter-contrib-gometalinter
Unfortunately there is no concept of a meta package yet. I've discussed the idea before under the name "bundle". I don't yet know when I'd be able to work on such functionality within Package Control, and currently there aren't really any other contributors.
Just so you know, what I am discussing here related to gofmt is my own personal thoughts, not me within any Go Team role.
I was thinking a "meta" package would just be an ordinary package that depends on golang-build, golang-format, etc. How would a bundle be different?
Packages can't depend on other packages, only dependencies, which are designed to handle non-user facing components that should be shared, are large (compiled shared libraries), or need to be injected into the Python load path before packages.
My idea with bundles is that they wouldn't be centralized. Thus people don't need to get their bundles approved or anything like that. They could just throw a JSON Object at any secure URL and users could load it. Ideally it would contain a list of packages to install, and possible to default settings to configure the settings for users.
If anyone wants to discuss more, let's move this to the Package Control issue tracker so we don't add more chatter to this issue.
Is this the best issue to follow regarding bundles? https://github.com/wbond/package_control/issues/1089#issuecomment-188955521
@paracha3 I'm not sure who is owning this repo at this point (in terms of making decisions). I'd personally be more in favor of a separate package that would reformat on save.
@nathany Yes, that is probably the closest thing right now.