We are already testing Go 1.13 in Fedora, and the latest build for F31 failed because of this.
https://koji.fedoraproject.org/koji/taskinfo?taskID=36633628

I've created the go1.13 branch with the first commit. The rest of the work still needs to be done by someone.

I've pushed one commit to go1.13 branch. It fixes build errors in sync package.

Next up we'll need deal with internal/reflectlite. It's a new internal package added in Go 1.13:

https://tip.golang.org/pkg/internal/reflectlite/

Package reflectlite implements lightweight version of reflect, not using any package except for "runtime" and "unsafe".

We'll need to find a way to implement it or find a way to make it not required by other packages. I tried two approaches unsuccessfully so far:

1. replacing all the internal/reflectlite imports with reflect:
   • this doesn't work because of import cycles: reflect imports errors which imports internal/reflectlite (which is exactly why the standard library needed to create a second reflect package)
2. copying reflect package source code (overrides) and trimming them down to what's needed
   • this is not easy because there's no clean subset of GopherJS's reflect package that will implement all of internal/reflectlite API; new code will need to be written and it may be a substantial effort that requires understanding how GopherJS implements and represents reflection (something I'm not closely familiar with, and we haven't created docs for it)

Stopping here for now, just wanted to post an update about some progress made. Others are welcome to pick it up from here if you have the bandwidth.

Any ETA on this?

Bump.

FWIW I have an 80% working 1.13 branch at myitcv#50

Tests are currently the only known outstanding item. i.e. gopherjs test needs some reworking. Otherwise, using gopherjs serve appears to work.

@myitcv I did some tests with my app against wasm. Unfortunately as of now without significant optimization work, wasm will quickly run out of memory and consumes a ton of CPU

I know that this will improve with work to the Go compiler as well as new features / design aspects being ironed out in WebAssembly. But it also seems to be a bit /too/ alpha to use for even a moderately critical application, while the JavaScript approach seems like it will work well in a lot of environments for quite some time to come.

For that reason I think the Go to Js approach will be useful and viable for a long time. Thank you for your work towards go1.13, I will test it and let you know if I find any quirks.

Hi @myitcv, I'm interested in making 1.13 support happen sooner. Anything in particular I could help with? :)

@myitcv There's currently over 1200 lines of code hidden in your branch in the "tool.go" and similar files in the root of the gopherjs repository. That code is not accessible by my code importing the "gopherjs/build" pakages directly. Would it be possible to move that common code used to generate the arguments for NewSession() (including imports) to a package where I can access it externally?

@nevkontakte - if you're happy to jump in and start fixing things up on myitcv#50 then please do, just give me a heads up on what you're planning to work on. Otherwise I will get to doing bits and pieces as and when I can. Verifying your applications work with that branch is probably one of the biggest helps, save the fact that gopherjs test does not work per above.

@paralin following on from our conversation in #855, my primary focus has been on a minimal working solution. I think we can look to "fix" the API of gopherjs/build afterwards.

@myitcv No worries, I was just posting a comment about it to keep it in the discussion. I can always modify the code myself in the meantime anyway. I appreciate the work & will keep testing the CLI version for now.

Thanks @myitcv, I'll see what I can help with. I'll continue with my questions on your PR if you don't mind.

I got an error when compiling go code to js. My code structure is like:

//main.go to compile to js
package main
import "abc"
func main() {
// do something with abc
// js.Global.Set(...)
}

//abc.go
package abc
import "bytes"
func TestGopher() bool {
buf := new(bytes.Buffer)
if buf != nil {
return true
}
return false
}

When compile, gopherjs output:
../../../../../usr/local/go/src/sync/waitgroup.go:93:36: too many arguments

My Go version is 1.13.5 and gopherjs version is 1.13-3, running on MacOS 10.15.1.

I am new to GopherJS and there could be something I missed to encounter this problem, and I spent hours to track it down. Pls anyone help me out.

Go 1.13 is not supported yet.

Any updates?

🙏 @myitcv @dmitshur any progress? Anything we can help with? I am already starting to use docker containers with a downgraded Go just to use GopherJS.

I am already starting to use docker containers with a downgraded Go just to use GopherJS.

Just FYI, this should not be necessary any longer. You can now run GopherJS 1.12 with Go 1.13. This is what I've been doing. You'll need to follow the updated installation instructions.

Fixed with #1015