Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
README: Suggest working with Go packages by default.
When writing Go code that is something more than just a very short snippet, it helps to organize code as a Go package. It may contain 1 or more .go files in a directory. `go build` is primarily used with Go packages, as in `go build import/path`. We should suggest the same use of `gopherjs build`. That will make it easier for users to get started and grow their code, because they'll be able to split into multiple .go files without having to update their build step.
- Loading branch information
1e66ca3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth mentioning here that import paths relative to
.
are unsupported (per #148, #302)?1e66ca3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I kinda forgot about that. Thanks for bringing it up. I almost never use the raw
gopherjs build
, instead I'm typically either usinggopherjs serve
for prototyping orgopherjs_http.NewFS
for production use.However, just
gopherjs build
works to build the package in the current directory. I think fixing relative import paths may not be that hard and higher priority, so I'll take a look at tackling that.1e66ca3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing relative import paths for the CLI should be easy. Fixing them for import statements is more complicated.
1e66ca3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's very little need to fix them for import statement. Not much high quality Go code does that.