os: support TinyGo on js/wasm - #650
Open
0pcom wants to merge 1 commit into
Open
Conversation
TinyGo's os package does not define Chmod, Chown or Link on the js/wasm target, so afero does not compile there at all. Route those three through small wrappers and supply js/wasm-only stubs returning ENOSYS, which is honest: that target has no filesystem for them to act on. syscall.EBADFD is likewise absent there, so BADFD falls back to EBADF. Scoped to js/wasm rather than to TinyGo as a whole: TinyGo's linux and wasip1 targets provide all three functions and keep using the standard implementations, verified by building against both.
|
|
0pcom
added a commit
to 0magnet/afero
that referenced
this pull request
Aug 16, 2026
The shims were gated on //go:build tinygo, which is too broad. Only TinyGo's js/wasm target is missing os.Chmod, os.Chown and os.Link — its linux and wasip1 targets provide all three, and were being given ENOSYS stubs for functions that work. Checked per target rather than assumed: tinygo linux — present tinygo wasip1 — present tinygo wasm/js — absent Same for syscall.EBADFD, which drives the BADFD fallback. Files renamed to match the narrowed constraint. This matches what was proposed upstream in spf13#650.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TinyGo's
ospackage does not defineChmod,ChownorLinkon its js/wasm target, so afero does not compile there at all. This routes those three through small wrappers and adds js/wasm-only stubs returningENOSYS— honest for a target with no filesystem to act on.syscall.EBADFDis likewise absent, soBADFDfalls back toEBADF.Scoped to js/wasm, not to TinyGo generally. That distinction is the reason for the odd-looking
!(tinygo && js)constraints. I checked each target rather than assuming:os.Chmod/Chown/Linklinux(native)wasip1wasm(js)So TinyGo native and wasip1 builds keep the existing implementations; only js/wasm diverges.
Verified:
go buildandgo teston the host pass unchanged;tinygo buildsucceeds for both thelinuxandwasip1targets; andgo list -tags tinygounderGOOS=jsselects exactly the two new files and none of the originals.One thing I should be straight about: this is necessary but not by itself sufficient to build afero under TinyGo js/wasm today. With TinyGo 0.41.1 the build still fails afterwards inside
net/http(roundtrip_js.go), which afero reaches throughHttpFs. That is a TinyGo stdlib gap unrelated to this change, and it is being pursued separately — but I would rather say so than let the PR imply the target works end to end.