README: document the current GOOS and GOARCH values

dmitshur · dmitshur · commit 51a54c3702ae · 2023-01-03T07:57:16.000-05:00
GopherJS 1.18 has standardized on a single value for GOOS and GOARCH in PR #1111. Update the README accordingly. (There has been agreement in issue #1169 that it's okay to be updating the top-level README for GopherJS 1.18-specific changes by now.) Also reword advice in compatibility.md to be more general. The upstream Go WebAssembly port (i.e., GOOS=js GOARCH=wasm, and notably not wasm64) is limited to 4 GiB of linear memory, it just happens to at this time use 64-bit variables for int/uint/uintptr types. So maybe it's not a great example to refer to. But a reminder that some types vary in size based on the architecture or implementation is probably worth including anyway.
diff --git a/README.md b/README.md
@@ -155,7 +155,9 @@ For more details see [Jason Stone's blog post](http://legacytotheedge.blogspot.d
 
 #### General
 
-GopherJS emulates a 32-bit environment. This means that `int`, `uint` and `uintptr` have a precision of 32 bits. However, the explicit 64-bit integer types `int64` and `uint64` are supported. The `GOARCH` value of GopherJS is "js". You may use it as a build constraint: `// +build js,-wasm`.
+GopherJS emulates a 32-bit environment. This means that `int`, `uint` and `uintptr` have a precision of 32 bits. However, the explicit 64-bit integer types `int64` and `uint64` are supported.
+
+The `GOOS` value of this environment is `js`, and the `GOARCH` value is `ecmascript`. You may use these values in build constraints when [writing platform-specific code](doc/compatibility.md#how-to-write-portable-code). (GopherJS 1.17 and older used `js` as the `GOARCH` value.)
 
 #### Application Lifecycle
 
diff --git a/doc/compatibility.md b/doc/compatibility.md
@@ -58,7 +58,7 @@ Also be careful about using GopherJS-specific packages (e.g. `github.com/gopherj
 
 GopherJS implements `syscall/js` package, so it _should_ be able to run most code written for WebAssembly. However, in practice this topic is largely unexplored at this time.
 
-It is worth noting that GopherJS emulates 32-bit environment, whereas Go WebAssembly is 64 bit, so you should use fixed-size types if you need to guarantee consistent behavior between the two architectures.
+It is worth noting that Go predeclares both architecture-independent [numeric types](https://go.dev/ref/spec#Numeric_types) (`int32`, `int64`, etc.) and ones with implementation-specific sizes (`int`, `uintptr`, etc.). Pay attention to this distinction to avoid portability issues between 32-bit and 64-bit platforms.
 
 🚧 If you have first-hand experience with this, please consider adding it to this section!
 
