[TS] Update README to describe TS as "early alpha" 🚀
authorMatt Corallo <git@bluematt.me>
Sat, 8 Jan 2022 17:48:28 +0000 (17:48 +0000)
committerMatt Corallo <git@bluematt.me>
Mon, 10 Jan 2022 19:47:27 +0000 (19:47 +0000)
README.md

index 825c22c716380b2e71be5275842ac9507ad70cbd..793d2ce8cf78f03086cf0598a2e9cf88119afb35 100644 (file)
--- a/README.md
+++ b/README.md
@@ -39,7 +39,7 @@ To build for Apple M1 (ie aarch64-apple-darwin), you probably want something lik
 Status
 ======
 
 Status
 ======
 
-The TypeScript Bindings are still in early development and generated code contains syntax errors.
+## Java
 
 While the underlying library and C bindings are relatively mature, the Java bindings should be
 considered beta quality and some issues may still appear. Specifically, because the Java bindings
 
 While the underlying library and C bindings are relatively mature, the Java bindings should be
 considered beta quality and some issues may still appear. Specifically, because the Java bindings
@@ -53,6 +53,17 @@ exit there will likely be many false positives. While it will require some compl
 are likely some use-after-free or unkonwn-free bugs remaining. The debug-mode build links LLVM
 address sanitizer and will print diagnostic information in case of such issues.
 
 are likely some use-after-free or unkonwn-free bugs remaining. The debug-mode build links LLVM
 address sanitizer and will print diagnostic information in case of such issues.
 
+## TypeScript
+
+The TypeScript bindings are functionally complete, but should be considered early alpha quality.
+Some functions may error spuriously due to oversights or missing implementations.
+
+The TypeScript bindings require modern web standards, including support for `FinalizationRegistry`
+and `WeakRef` (Chrome 84, Firefox 79, Safari 14.1/iOS 14.5 and Node 14.6) and WASM BigInt support
+(Chrome 85, Firefox 78, Safari 14.1/iOS 14.5, and Node ??).
+
+## General
+
 The only known issue resulting in a use-after-free bug requires custom a custom ChannelKeys instance
 created as a part of a new channel. After the channel is created, the ChannelKeys object will not
 be freed while the parent ChannelManager exists, however if the ChannelManager is garbage collected
 The only known issue resulting in a use-after-free bug requires custom a custom ChannelKeys instance
 created as a part of a new channel. After the channel is created, the ChannelKeys object will not
 be freed while the parent ChannelManager exists, however if the ChannelManager is garbage collected