Thanks for the PR!

I am personally still pretty confused by the empty.go files and why they're necessary. Can you be sure to update CI to fail if they're not present? I'm not sure why things are working for me locally but then they keep failing for users consuming this package?

Does this mean that everyone has to import with a _ the header file directory now too? If that's the case I'd rather fix this via some other means because I don't want to have to force all consumers to import internal details like that.

I'm not sure why things are working for me locally but then they keep failing for users consuming this package?

It depends if you use dependency vendoring. By default, you don't, and everything is fine. Your don't have to import anything but github.com/bytecodealliance/wasmtime-go.

However, some projects use go mod vendor to make a local copy of their dependencies. In that case, Go uses creates and manages a directory vendor in the root directory of the project, and copies the vendored dependencies in it. Then Go uses this local copy of the dependencies to build the project. But as it copies only the packages that are referenced in the code, it does not copy the build directory, which is then not available for consumers :-(

You can try go mod vendor in a module-enabled version of your "hello world" example to reproduce the issue.

Does this mean that everyone has to import with a _ the header file directory now too? If that's the case I'd rather fix this via some other means because I don't want to have to force all consumers to import internal details like that.

At least one project uses this _ "hack" to reference the build subdirectories and copy them in their vendor directory: https://github.com/open-policy-agent/opa/blob/f1104893cbac176e0a9b752ba67a43af0d8ec0b0/internal/wasm/sdk/internal/wasm/vm.go#L16-L19

But it's because they decided to use this vendor feature; that's not the case for the majority of go projects.

Ah ok that makes sense, thanks for the info! Is it possible to move those import directives into this package itself without disrupting other users? Linked from that issue is another style like https://github.com/godror/godror/pull/38/files, and would something like that work?

In either case, though, I'd ideally like to add a test on CI that this works. This is something that I'll undoubtedly regress and break in the future otherwise after I forget...

Is it possible to move those import directives into this package itself without disrupting other users? Linked from that issue is another style like https://github.com/godror/godror/pull/38/files, and would something like that work?

Yes, that's way better!

In either case, though, I'd ideally like to add a test on CI that this works. This is something that I'll undoubtedly regress and break in the future otherwise after I forget...

Sure, I'll add a CI test for that.

I've updated the PR:

• Import build packages, to prevent go mod vendor from pruning the build directories;
• Update download-wasmtime.py to re-create the "empty.go" files and keep the Go packages in "build"
• Add a CI test to check that wasmtime-go can be used by Go projects using dependency vendoring

If an empty.go file is missing, go build will fail as the packages are imported in ffi.go. If an import is missing in ffi.go, the script ./ci/test-vendoring.sh fails in CI.

Bazel is failing. I guess I should add the import in BUILD.bazel... (I don't know bazel)

Looks great to me! But yeah unfortunately I don't really know much about BUILD.bazel either...

Ok. I'm testing it locally with Bazel.

I've moved the "_" imports to a unused file (not in Bazel, and excluded from build by a build constraint); it seems to fix the Bazel issue, and it still makes go mod vendor to copy the headers and binaries.

Looks great to me, thanks again for this!