Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing various net/http packages in std #4580

Closed
Flo4604 opened this issue Nov 3, 2024 · 6 comments
Closed

missing various net/http packages in std #4580

Flo4604 opened this issue Nov 3, 2024 · 6 comments

Comments

@Flo4604
Copy link

Flo4604 commented Nov 3, 2024

I am currently trying to build my net/http server and getting various errors

Running: tinygo build -o ./build/app.wasm -target wasm -no-debug ./cmd/main.go

package net/http/httptest is not in std
package net/http/httptrace is not in std
package net/http/cookiejar is not in std
package net/http/httputil is not in std

Anything I can do to bypass this?

@elewis787
Copy link

elewis787 commented Nov 7, 2024

According to https://tinygo.org/docs/reference/lang-support/stdlib/#nethttphttptrace the packages you are trying to import are not supported.

Can you share more about what you are trying to do with the HTTP server? I see you are targeting wasm.

HTTP in WASM can be tricky. However, there are a few examples of how you can use wasip2 and a runtime such as wasmtime to run something close.

Here is one project https://github.com/rajatjindal/wasi-go-sdk/tree/main/examples. Wasmcloud, Spin, Wasmtime, and Extistim are a few tools you could look into if you are working with wasm server side.

If you are using wasm in the browser, that will be a different story.

@Flo4604
Copy link
Author

Flo4604 commented Nov 7, 2024

I was trying to use https://github.com/syumai/workers, but my current HTTP Server has a lot more extra dependencies such as tracing, so I think its just not cut out for my case atm.

I will look into wasip2 and see if cloudflare has support for that.
Thanks for the reply and sorry for not reading docs first

@Flo4604 Flo4604 closed this as completed Nov 7, 2024
@inliquid
Copy link

inliquid commented Nov 7, 2024

I have same issue when trying to build module, which imports quite complex *.proto definitions:

$ tinygo build -o wasm/plugin.wasm -scheduler=none -target=wasip1 --no-debug ./wasm
../../../../pkg/mod/golang.org/x/[email protected]/http2/transport.go:26:2: package net/http/httptrace is not in std (/home/***/.cache/tinygo/goroot-8cbcb1d9555609a60075264735fce03217a624835ebf583eb96aa0c5bf08e840/src/net/http/httptrace)
../../../../pkg/mod/google.golang.org/[email protected]/internal/transport/proxy.go:29:2: package net/http/httputil is not in std (/home/***/.cache/tinygo/goroot-8cbcb1d9555609a60075264735fce03217a624835ebf583eb96aa0c5bf08e840/src/net/http/httputil)

I think problem is there and needs to be fixed. Can we keep issue open, or should I open another one?

@elewis787
Copy link

@inliquid - I believe the main problem is the deps that are getting pulled in by grpc.

One solve for this would not be handled in tiny-go. Recently the tiny-go net package was updated to handle custom transports for HTTP. This was a core requirement for getting HTTP in wasi working IMO.

There might be something that could be done using a similar pattern but it will be in the packages uses x/net or grpc.

Otherwise, you are right these packages would need to be pulled over into tinygo - I haven't looked into that but my guess is that is fairly far out - just a guess tho.

I don't see a problem leaving this issue open - but I would also recommend looking here https://github.com/tinygo-org/net to see what we could do.

@inliquid
Copy link

inliquid commented Nov 8, 2024

Otherwise, you are right these packages would need to be pulled over into tinygo - I haven't looked into that but my guess is that is fairly far out - just a guess tho.

I would like to be able to just compile these dependencies into my Wasm modules. And I see a lot of progress, previously there were much more scaring compiler errors, now when reflect support is there, only those left. At the moment I have to regenerate these *.proto definitions using alternative generators.
So can you please reopen it, and keep for tracking of similar issues? I understand that it's not that easy.

@inliquid
Copy link

Opened #4598.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants