go-plugin VS goja

I am looking forward to a mix of both - I am hoping to add a concept called "operator" which would be a go-plugin [1], just like terraform providers, but build backends. So, someone would be able to, say, write a Slack plugin (in Go, or anything over RPC) which sends a message once a build is complete - like Jenkins/GitHub actions, or just scripts that we can reuse like GitLab CI through `modules`.

Perhaps a new registry where we can push custom modules and providers (operators in this case), I'm curious to know about if we have any existing implementations we could reuse for the registry.

[1]: https://github.com/hashicorp/go-plugin

I'd recommend looking into a different approach for plugins such as hashicorp/go-plugin (which uses multiple process PIDs and RPC communication between them) or traefik/yaegi (which implements a Go-compatible scripting language that can be interpreted at runtime and which still supports most Go modules).

You'll never fully protect your code from someone who's dead-set on reverse-engineering it, however, you can use https://github.com/hashicorp/go-plugin or a similar RPC technique, which will let you ship binary plugins and will also be less fragile and janky compared to something made with `-buildmode=plugin`.

The plugin system that hashicorp uses for all their projects works very well. It's essentially a local RPC implementation. https://github.com/hashicorp/go-plugin

can you try older go-plugin versions? The only major change in v1.4.4 was a bugfix for automtls. https://github.com/hashicorp/go-plugin/blob/master/CHANGELOG.md

dop251/goja

Your comment was posted 4 minutes ago. That means you still have enough time to edit your comment to change it so it contains real URLs:

<https://github.com/PuerkitoBio/goquery>

<https://github.com/dop251/goja>

(Please do not reply to this comment—I won't be able to delete it once the previous post is fixed if it contains replies.)

Apparently "not depending on Node or V8" means depending on some random Go JS engine instead.

Goja https://github.com/dop251/goja

Either call a JavaScript interpreter like node with exec.Command and read its stdout, or use a pure Go JavaScript interpreter like goja or otto.

Just to also say this is implemented in pure Go we aren't including V8 or any external dependencies we instead use https://github.com/dop251/goja which is a JS VM written completely in Go.

If you want to serialize a function to JSON one idea may be to embed a scripting language like JavaScript into your program. The goja package is a very good solution: a native ES5 JavaScript (with some ES6 syntax support as well) natively implemented in Go so you can get tight data bindings to your Go types and funcs. For your JSON marshalling you could serialize a JavaScript function source (text) and when reloading that, parse that text with goja to be able to run it dynamically in your Go program. Basically you'd need to get away from pure Go for this and towards something that is JSON compatible to (de)serialize to text.

Not really. It was built in-house and I don't know of anything about it that went public. I recall it using Goja for the JS runtime. Code was embedded into the binary (think embed package). There was some kind of sorcery to convert what would be HTTP network calls in the browser into local function calls during SSR, but I'm hazy on how it worked I'm afraid.