v0.24.0

• Buffer API support (#13)
  • napi_create_buffer
  • napi_create_external_buffer
  • napi_create_buffer_copy
  • napi_is_buffer
  • napi_get_buffer_info
• emnapi_create_memory_view (#20)
• Fix string decoding (#19)
• Fix init order (#18)
• Change emnapi_sync_memory signature

  napi_status emnapi_sync_memory(napi_env env,
                                 bool js_to_wasm,
                                 napi_value* arraybuffer_or_view,
                                 size_t byte_offset,
                                 size_t length);

  declare function emnapiSyncMemory<T extends ArrayBuffer | ArrayBufferView> (
    jsToWasm: boolean,
    arrayBufferOrView: T,
    byteOffset?: number,
    length?: number,
  ): T

Great thanks to @RReverser

v0.23.0

• Add napi_create_external_arraybuffer, the ArrayBuffer memory is copy from wasm, use emnapi_sync_memory to sync memory between wasm and JavaScript, use runtime method $emnapiSyncMemory on JavaScript side

  void finalizer(napi_env env, void* finalize_data, void* finalize_hint) {
     free(finalize_data);
  }
  
  napi_value createExternalArraybuffer(napi_env env, napi_callback_info info) {
    uint8_t* external_data = malloc(3);
    external_data[0] = 0;
    external_data[1] = 1;
    external_data[2] = 2;
    napi_value array_buffer;
    napi_create_external_arraybuffer(env, external_data, 3, finalizer, NULL, &array_buffer);
  
    external_data[0] = 3; // JavaScript ArrayBuffer memory will not change
    emnapi_sync_memory(env, array_buffer, 0, external_data, NAPI_AUTO_LENGTH, false);
    // after sync memory, new Uint8Array(array_buffer)[0] === 3
  
    return array_buffer;
  }

  declare function emnapiSyncMemory (
    arrayBufferOrView: ArrayBuffer | ArrayBufferView,
    offset?: number,
    pointer?: number,
    len?: number,
    js_to_wasm?: boolean
  ): void
  
  const array_buffer = Module.emnapiExports.createExternalArraybuffer()
  new Uint8Array(array_buffer)[1] === 4
  Module.emnapiSyncMemory(array_buffer, 0, 0, -1, true)

• ArrayBuffer related API always return data pointer, the memory could be a copy from JavaScript ArrayBuffer, use emnapi_get_memory_address to check if the memory should be released by user,

  • napi_create_arraybuffer
  • napi_get_arraybuffer_info
  • napi_get_typedarray_info
  • napi_get_dataview_info

  void* data;
  napi_get_typedarray_info(env, typedarray, NULL, NULL, &data, NULL, NULL);
  
  void* address;
  emnapi_ownership ownership;
  bool runtime_allocated;
  emnapi_get_memory_address(env, typedarray, &address, &ownership, &runtime_allocated);
  assert(address == data);
  if (data != NULL && runtime_allocated && ownership == emnapi_userland) {
    // user should free data
    // free(data);
  }

v0.22.0

Improving performance (2x ~ 3x)

v0.21.1

fix #10

v0.21.0

• refactor @tybys/emnapi-runtime
• Optional API Module.emnapiRuntime and Module.emnapiContext has changed.

See https://github.com/toyobayashi/emnapi/blob/v0.21.0/packages/emnapi/src/init.ts#L49-L138

<script src="node_modules/@tybys/emnapi-runtime/dist/emnapi.min.js"></script>
<script>
var Module = {}
Module.emnapiRuntime = window.emnapi
window.__emnapi_context__ = window.emnapi.createContext()
Module.emnapiContext = window.__emnapi_context__
</script>
<script src="emscripten-glue.js"></script>

v0.20.0

• feat: add predefine options: EMNAPI_WORKER_POOL_SIZE, EMNAPI_NEXTTICK_TYPE, EMNAPI_USE_PROXYING
• refactor: add uv.h and port libuv's threadpool to schedule async works.
• fix: #8

Breaking Changes

If you use multithreading API such as napi_*_async_work or thread safe functions, you need to build additional source files (src/uv/**/*.c), so you need to add them to your makefile or build script, or directly use CMake add_subdirectory() and target_link_libraries().

v0.19.2

• fix: napi_get_all_property_names filter
• refactor: rename emscripten parse tool macro with prefix "$"

v0.19.1

• refactor: use makeGetValue/makeSetValue

v0.19.0

• feat: support MEMORY64 (#7)

v0.18.3

• Fix on emscripten >= 3.1.17 #6