I don't see why not.

In fact, I would be inclined to think the only reason it's not already the case is because of a bug or unintended omission.

Unless I'm missing something and there was a reason this .inc.js thing was added for main packages only?

That said, this is another feature I do not plan to use much myself, if at all. But if others want to, I think they should be able to. It should probably not be recommended unless appropriate for the situation.

Unless I'm missing something and there was a reason this .inc.js thing was added for main packages only?

Now that I think about it more, it might be on purpose.

Adding additional JavaScript makes sense when building the final output, such as the case for a main Go package. But if it's done on a per-package level, it may cause conflicts between different packages, etc.

So, I probably take back what I said above.

Yes, that's true. For it to really work well, it would almost certainly have to be in some sort of a CommonJS-style closure. And trying to mix that with GopherJS doesn't sound fun.

(Oops, didn't mean to close it just yet... although that's probably going to be the eventual fate of this anyway).

Yeah, let's wait to hear thoughts of @neelance (and maybe @dominikh) on this.

I think it's reasonable to make it work with all packages. I don't know why it currently does not work, it was not on purpose. @flimzy Would you like to dig into that or should I take a look?

I'll take a crack at it.

What are your thoughts on @shurcooL's point about conflicts? I suppose just trust users not to let that happen?

Yeah, bad things can be done in a lot of ways. This however does not seem like an explicit invitation to do so. ;-)

My investigation has lead me to the conclusion that the failure I observed is not specifically with non-main packages, but rather that gopherjs test fails to include *.inc.js files.

This also lead me to discover that gopherjs build only includes the *.inc.js files when they are explicitly mentioned on the command line:

gopherjs build jstest.go jstest.inc.js

But doing this with gopherjs test is not supported:

$ gopherjs test jstest.go jstest.inc.js 
cannot find package "jstest.go" in any of:
    /usr/local/go/src/jstest.go (from $GOROOT)
    /home/jonhall/go/src/jstest.go (from $GOPATH)

It appears that build accepts file names (even though gopherjs help build claims it needs package names--but go build seems to exhibit the same inconsistency). However, gopherjs test enforces the documented behavior of only allowing package names.

I'm willing to continue working toward a fix, but I think I need some guideance from you, @neelance, as to what the intended behavior for gopherjs build and gopherjs test are with respect to *.inc.js files.

This also lead me to discover that gopherjs build only includes the *.inc.js files when they are explicitly mentioned on the command line:

gopherjs build jstest.go jstest.inc.js

Just want to confirm, do you mean that doing gopherjs build would not include .inc.js files?

That is correct. That is my observation.

I'm testing with this repo: https://github.com/flimzy/jstest

If I do gopherjs build, then gopherjs build jstest.go jstest.inc.js, the results differ as follows:

--- 1.js        2015-09-17 00:46:22.546548624 -0500
+++ jstest.js   2015-09-17 00:46:38.542719761 -0500
@@ -14947,6 +14947,10 @@
})();
$packages["main"] = (function() {
        var $pkg = {}, $init, fmt, sliceType, main;
+       (function() {
+console.log("Included the JS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!")
+
+       }).call($global);
        fmt = $packages["fmt"];
        sliceType = $sliceType($emptyInterface);
        main = function() {

I've been distracted the last several weeks by an international move. I'll finish investigating my fix in #322 over the next few days as time permits.

Resolved with #322.