cc @mvdan - this should make the wrapping of https://godoc.org/mvdan.cc/sh/syntax much easier.

Would this be a breaking API change for js.MakeWrapper users, or is it backwards compatible?

Would this be a breaking API change for js.MakeWrapper users, or is it backwards compatible?

Yes, I think it is backwards compatible, because we are only adding properties to the returned value.

I've just pushed up a revised version with a test that demonstrate a more interesting scenario, asserting both ways for the getter and setter.

I can vouch for the awesomeness of this PR. It has enabled me publishing a rough first version of a Go package of mine on NPM: https://www.npmjs.com/package/mvdan-sh

I can't speak about the code itself much, but it works very well :)

@hajimehoshi @shurcooL - this is now ready for review.

@mvdan - would appreciate if you can update us here on how your testing with this has gone? Thanks very much for helping to road-test the changes.

The code that I have been using to expose the Go package as a JS module is here: https://github.com/mvdan/sh/tree/master/_js

So far it works great with a minimal amount of boilerplate. I have been pinging Paul about specific runtime errors and problems that I was hitting, which he has been pushing fixes here for. At this moment, MakeWrapper is definitely useful to me, as all the basic features of the Go library work great in JS.

I hope to get at least a few considerable users of the JS module in the next couple of weeks, so I am likely to provide more edge cases, potential bugs, and suggestions. But please don't let that hold back the reviewing and merging of this PR, as this seems like a great start to have in master.

@mvdan - rebased this against recent merges into master. Just an FYI for when you're testing things out.

Everything still works perfectly, at least as far as I have used and tested it.

Just yesterday I was finally able to pass objects back and forth between JS and Go multiple times. So now, with the shell package, one can parse a shell program (Go -> JS), walk the syntax tree (JS -> Go and Go -> JS for the callbacks), modify nodes, and print the modified shell source code back (JS -> Go).

The glue code is still in that _js dir I pasted above, if anyone is curious: https://github.com/mvdan/sh/blob/master/_js/main.go

No further requests or bug reports from me :) Happy to continue using this and report bugs on the tracker, once this is merged.

cc @mpl - this approach could I think help in perkeep world. Avoids the need for any serialising etc. Will ping you more details offline

@myitcv ACK, thanks. next week though. busy with preparing release/presentation this week.

Perhaps I'm missing something as I'm not involved in GopherJS development - has there been any progress in getting this reviewed and merged? :)

GopherJS seems frozen right now! Need a merge here too :)

If anyone else needs this, just use Paul's fork at https://github.com/myitcv/gopherjs - it includes this enhancement, as well as others like Go module support.

Just one note @mvdan - all this is currently sitting in the https://github.com/myitcv/gopherjs/tree/go1.11 branch of my fork.

There is a chain of PRs that, once merged, will enable full versioning of the fork with versions like 11.0.0 which will correspond to Go 1.11, 11.1.0 which will correspond to Go 1.11.1, 11.1.1 which will correspond to a point release of GopherJS between Go 1.11.1 and Go 1.11.2 etc.

Is this going to happen?

@JounQin If memory serves, @flimzy and I discussed this and it seemed like a good thing to have, but it needs to be rebased before if can be merged. One of us was going to do it once there isn't a more pressing matter (like Go 1.18 support, sigh), but so far neither of us has gotten around to it. If you are interested and willing to do the rebase, it would be a welcome contribution.

@nevkontakte

See #1112.

I'm a js/ts frontend developer, not a go expert actually :(

Hope it helps.

@JounQin and I am not really a frontend developer (despite working on GopherJS), so our areas of competences together should give a pretty good coverage :) Thanks for doing the rebase, I'll close this PR then, and continue on #1112.