1.js后端目前也会限制ffi的传递类型,实际上是没有必要的
2.配置use-js-builtin-string后可在wasm-gc中使用String作为传递类型,构建通过但lsp还是会提示不支持,感觉需要在pkg.json里提供一个配置默认target给lsp进行检测
3.目前支持js-builtin-string的似乎只有部分浏览器和deno?node和bun都不支持
如果可以给wasm-gc后端生成dts和对应的glue.js就更好了
1.js后端目前也会限制ffi的传递类型,实际上是没有必要的
2.配置use-js-builtin-string后可在wasm-gc中使用String作为传递类型,构建通过但lsp还是会提示不支持,感觉需要在pkg.json里提供一个配置默认target给lsp进行检测
3.目前支持js-builtin-string的似乎只有部分浏览器和deno?node和bun都不支持
如果可以给wasm-gc后端生成dts和对应的glue.js就更好了
最简单的设想是导出一个函数
// 基于`WebAssembly.instantiateStreaming`
(Response | PromiseLike<Response>, ImportObject) => Promise<{
module: WebAssembly.Module
instance: WebAssembly.Instance & {exports: Exports}
}>
// 也可以考虑导出另一个同步函数,基于new WebAssembly.Module
(BufferSource, ImportObject) => ({
module: WebAssembly.Module
instance: WebAssembly.Instance & {exports: Exports}
})
根据target生成默认的配置(js-builtin-string,etc.),只向用户暴露需要传入的ffi对象
这样足够简单也对typescript项目比较友好,不需要写额外的断言
另外是否考虑支持从模块导入的ffi,以下是gleam中的写法
@external(erlang, "gleam_stdlib", "identity")
// @external(javascript, "@pkg/std", "to_unicode_str")
@external(javascript, "../parser_gleam_ffi.mjs", "to_unicode_str")
pub fn do_to_unicode_char(i: Int) -> c.Char
默认的wasm-gc后端可以结合上述glue.js的设想,从模块导入ffi也就可以直接写在glue.js里,由于buffer需要用户传入更为灵活,相对路径导入也会更简单
你似乎是要生成.d.ts?类似这样的功能:WebAssembly
从模块中导入FFI具体是什么意思?Wasm标准只定义了根据两个字符串定义导入。你的设想是在开发环境中已知有JS文件,生成的时候同时生成导入标识符与Import Object?
对,wasm后端在glue.js里生成相应的部分ImportObject,js后端可以直接编译为import statement而不用手写require这种很不自然的方式
生成.d.ts其实就是为glue.js生成dts,和运行时无关