CountBleck

> It can give more freedom to hook memory grow. Honestly the only use case I'm targeting is handling views of the Wasm memory being detached on `memory.grow()` in JS....

I'll pitch in my two cents. It might make sense to use JSDoc annotations in the existing binaryen.js-post.js file, and make any changes necessary for TypeScript to infer types for...

Frankly, AssemblyScript itself doesn't use the high-level APIs that are in binaryen.js, as far as I'm aware. It uses its own high-level wrappers found [here](https://github.com/AssemblyScript/assemblyscript/blob/main/src/module.ts). That means AS would do...

> Maybe you're missing the bit where binaryen.js is not even compatible with what's in this repo's JS bindings ? I don't follow. Are you referring to the .d.ts file...

I think he's referring to the typings in the binaryen.js repo becoming out of sync with changes in the binaryen.js-post.js file here. That can only be avoided if binaryen.js-post.js here...

> Would this perhaps become simpler[...]? Oh, that's...a much better idea. Thanks and sorry about that.

> Might well be a non-issue in practice, though. @dcodeIO hmm, would this conflict when `--importMemory` is specified without `--zeroFilledMemory`?

@HerrCai0907 I changed the commit message; this is technically a breaking change.

Not yet. It's part of the plan though.

It's my fault, sorry. I haven't implemented a good polyfill yet, and we need that before switching over to Wasm GC.