TinyGo compatibility

[srenatus]

This is for tracking issues, and for gauging interest in supporting TinyGo for building (parts of) OPA.

The reason is that TinyGo seems to be the preferred way (over the stdlib wasm support) to build Wasm modules from Golang code.

I've previously played with making the parser TinyGo-compatible, but it required a few rather blunt measures, see this branch.

If there is community interest in this, we could try to figure out -- more systematically -- what we've got to change to make (some portions of) OPA TinyGo compatible.

Related #2152 -- that package's use of the runtime broke TinyGo at some point in the past.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[srenatus]

https://github.com/tinygo-org/tinygo/issues/1306 the regexp bit may have gotten resolved 🥳

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.

[nschejtman]

This feature would be nice, as @srenatus mentions TinyGo's support for WASM is better than the stdlib, specially for libraries.

One thing that could help is splitting the different OPA components in separate modules so one can import only the needed ones. TinyGo doesn't have the same SDK as standard Go. The tree shaking happens in a later stage so those unused bits still get compiled (despite not being used), and compilation might fail due to these SDK differences. Having separate modules could be like a pre-tree shaking. Will also help not getting irrelevant security issues from many code analyzers like Snyk or NexusIQ.

[nschejtman]

So far I run into many SDK issues with this depedency github.com/rcrowley/go-metrics but I managed to workaround that replacing the dependency in the go.mod file with a local version that only keeps the relevant parts to OPA. Now I'm stuck with this:

# github.com/open-policy-agent/opa/topdown
../../go/pkg/mod/github.com/open-policy-agent/[email protected]/topdown/net.go:18:19: undefined: net.Resolver

I cannot replace the SDK net package so I think I would just fork OPA and remove that, which is unfortunate because it will make upgrading more complex.

[srenatus]

So splitting OPA into modules is a nice idea, for other reasons, as you mentioned. It would be awesome if you could use the core rego functionality without dependency on, say, opentelemetry. 😅 However, it's impossible to pull off while keeping compatibility, I'm afraid. So this would have to be a breaking change that's carefully implemented and planned....

On a related note, your output says 0.47.0, that's pretty old. I don't think you'll see a much improved situation with 0.58.0, but it's still better to stay on top of things.

I think introducing some build tags that allow you to disable certain parts of topdown would be possible to merge. It needs to be kept compatible, and not having the build tag set should be the current situation... What do you think?

[stale[bot]]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.