Wrongly generated .d.ts

[jerrygreen]

I've found a good issue here, and figured out that I can actually generate .d.ts by setting tsdFile option in config, and use AssemblyScript types inside TypeScript! Which is absolutely cool, but I found that automatically it actually generates slightly wrong hierarchy.

I have further AssemblyScript code:

export function add(a: i32, b: i32): i32 {
  return a + b
}

And a wasm module as a react component:

const AsmComponent = dynamic({
  loader: async () => {
    const wasmModule = await import('../../../asm/build/optimized') // <- imports `.wasm`

    return (props) => <>{wasmModule.add(1, 2)}</>
  },
  ssr: false,
})

And I render it in React like so:

          <p>Execute function from wasm module:</p>
          <p>
            1 + 2 = <AsmComponent />
          </p>

And it works:

So it works, but look at my types:

Property 'add' does not exist on type 'typeof import("c:/Users/Jerry/projects/project-x/asm/build/optimized")'

Now I can fix these types by replacing asmModule.add into asmModule.default.add:

But if I now run actual application, "default" doesn't actually have "add" function:

My automatically generated optimized.d.ts looks like so:

declare module ASModule {
  type i8 = number;
  type i16 = number;
  type i32 = number;
  type i64 = bigint;
  type isize = number;
  type u8 = number;
  type u16 = number;
  type u32 = number;
  type u64 = bigint;
  type usize = number;
  type f32 = number;
  type f64 = number;
  type bool = boolean | number;
  export function add(a: i32, b: i32): i32;
}
export default ASModule;

If I manually remove the namespace, leaving bare types like so:

type i8 = number;
type i16 = number;
type i32 = number;
type i64 = bigint;
type isize = number;
type u8 = number;
type u16 = number;
type u32 = number;
type u64 = bigint;
type usize = number;
type f32 = number;
type f64 = number;
type bool = boolean | number;
export function add(a: i32, b: i32): i32;

Then both types and actual code go aligned, and both working!

Pls can someone change how .d.ts file is generated, and generate it without a namespace?

[dcodeIO]

The bundler seems to make an assumption about how a .wasm file maps to a .d.ts, yet it may well be that AssemblyScript is the only tool currently emitting a .d.ts for a .wasm file (not 100% sure though), and it recommends to use it with the loader. I am not opposed to change the way this works, however, especially with esm-integration looming, but since this is a breaking change it would be good to evaluate if there are any clear signals for this case from standards bodies, or TS for that matter, yet, so it becomes unlikely that we'll have to change this again in the future.

[jerrygreen]

@dcodeIO this loader seems to be some glue code for environments where dynamic imports of wasm modules doesn't work and require fetching the module, maybe some older node versions, maybe for esm modules, or idk... But you can clearly see that no any glue code required here (if anyone interested, I used Node 14.15.2, Typescript 4.1.5, NextJS 10.0.7, React 17.0.1), so this loader is kinda unneeded (again, I admit it still might be needed for some other environments though).

Anyway, from what I see from VSCode right now, the generated types are not aligned with actual values here. If I decided to fix how imports work, to change the value structure to make them fit for existing types, - this would be a hugely breaking change, since that would change how code works. But this particular fix does not change how code works, and only changes how types are being generated, so even though breaking, it's very little breaking change, very few people will notice that. Because, for starters, it is an optional feature that is disabled by default and has to be enabled in asconfig.json:

{
  "targets": {
    "release": {
      "tsdFile": "src/build/optimized.d.ts" // <--- not generated if not set
    }
  }
}

Another point: it's not even featured in docs (I myself found it in this issue, and otherwise wouldn't know it's possible to generate .ts.d file):

I agree that people that are using tsdFile feature, - their AsmModule types will broke upon updating AssemblyScript compiler. But asc's major version is still currently 0, so I assume people might expect something like that, and be ready to fix that upon updating. For the rest people, like who are starting new AssemblyScript projects, - for them it will simplify the developer experience because no loader required. So to me it looks like: "omg let's get this merged asap" actually.

I'm not sure what you expect from me particularly... To ping some people from TS team or something? "standards bodies, or TS for that matter", - I don't get it...

[jerrygreen]

@dcodeIO I just found those imports don't work in pure Node with default flags though, - node doesn't support import syntax for wasm modules. But if you pass --experimental-wasm-modules argument to node, then it will work. Though in my particular environment I use NextJS and I suppose it has webpack config to make that happen rather than node experimental flag, but they both seem to use the same approach. In this article you can find code samples with the same exact code and structure:

https://www.joyent.com/blog/improved-wasm-support-coming-to-node#importing-webassembly-modules

'use strict';
(async () => {
  const example = await import('./example.wasm');

  console.log(example.addTwo(8, 5));
})();

So look, it worked like years ago (like a couple years ago, maybe more?). So I guess this structure is right. Idk why current declaration file wraps it into some kind of namespace (confusingly naming it "module" too), it doesn't make sense. No wrappers needed

P.S. Sorry for some kind of pressure, I just really want it to land, so I can easily yarn add assemblyscript, and have comfort tinkering things while having auto-generated types that I don't have to fix manually

P.P.S. the only real difference here is that it the code above uses fullname example.wasm rather than extension-less variant. So I guess in my environment some webpack magic involved, most likely by NextJS

[dcodeIO]

I only want to make sure that when we change it, we better be sure that it "just works". In general I think that what you are proposing makes sense, but that it already works in bundlers (with a .d.ts) seems more like a coincidence than anything else, because noone but AS does it. Hence I'd appreciate if we could double check that it doesn't unexpectedly conflict with ESM-integration or what TS may be doing in the future, if TS has even thought about this already.

[jerrygreen]

@dcodeIO I see... I added a couple integrated tests to the existing PR, that do the whole cycle:

1. Use existing asc to compile simple wasm module with add function into .wasm file
2. Use -d (--tsdFile) option to generate according .wasm.d.ts (using the new structure of .d.ts file)
3. Have typescript file that is using this .wasm module
4. Have typescript compiler involved to make sure it can find corresponding types (it will fail if it won't find it)
5. Execute generated javascript to make sure the .wasm module works
6. And all that is included into npm run test command, to make sure those imports will work in the future, both js functionality and ts declarations

One thing to note that .d.ts file should have exactly the same name as .wasm module, with added .d.ts in the end, so VSCode is able to find those declarations.

Good:

optimized.wasm
optimized.wasm.d.ts

Bad:

optimized.wasm
optimized.d.ts