Now that this identifier is exported, it should have a doc string that describes what it does.

Also, according to Go style, the acronym should have the same case, so it's JSFilesFromDir, not JsFilesFromDir.

I don't mind adding a doc string, but the majority of methods in that file don't have any documentation (in fact, the only two I see that are documented aren't even exported), and function name itself is nearly self-documenting.

I also don't mind changing the capitalization of the function, but it's named after the JsFiles variable, which is capitalized this way, too.

but the majority of methods in that file don't have any documentation

I guess the Broken windows theory can be adapted to fit software development ;)

We can ask for @neelance's opinion on this.

My understanding is that GopherJS was initially an experimental project, back when it wasn't known if it'd be possible to support of all Go language's features and have good performance, so focusing on implementing functionality over documentation made sense since @neelance was the only developer.

Now that GopherJS has implemented the entire Go spec and has proven to be quite mature, reliable, performant, used in some production environments, and is getting more contributions from external people, I think it's a good idea to start caring about internal code quality, documentation more than in the past.

So I think it's a good idea to apply best practices for the new code being added, and also slowly work on improving existing code. Does that seem like the best way to go, or not?

Without a doubt, @dominikh. And I'm a huge advocate of the continuous improvement model, too, so as I said, I have no problem adding that. And I will add the documentation string when I have a chance, if the PR hasn't already been merged by someone by then.

@shurcooL, valid points, IMO.

(This sort of thing would fit well in a Developers' Guidelines, IMHO... Perhaps I should propose the development and formalization of such a guide in an issue)

I think we should apply the standards and guidelines of the Go community. If existing code can be improved, we should do so. JsFiles should clearly become JSFiles. Some more documentation would also be nice, however in this case I would like to avoid giving the impression that the build package is stable API. It does not feel ready to me. If we add more docs then we should warn in the package description about potential future changes.

Speaking of changes, making jsFilesFromDir exported seems wrong to me. This is an internal helper, the package should make all necessary cases available via higher-level API. Also adding this code do collectTests will probably include the .inc.js files twice.

The root cause is bad API of the build package. jsFilesFromDir should probably somehow move into the Import function and then there should also be an ImportDir function. It also occurred to me that Session.ImportPackage is probably a bad name, since it actually builds the package. Seems like I did not do a good job at this part of the codebase and it needs some refactoring to become nice.

Some more documentation would also be nice, however in this case I would like to avoid giving the impression that the build package is stable API. It does not feel ready to me. If we add more docs then we should warn in the package description about potential future changes.

Good point, agreed.