Handling AssemblyScript input files

[trusktr]

(Continuing from #10939)

I'd like to add another use case:

AssemblyScript. :)

It could be handy to have both .ts and .as files, to disambiguate the two.

For example, at the moment I have both src/ts/ and src/as/ folders to disambiguate the two.

It would also then be possible to have both some-project/index.ts and some-project/index.as, and which one is being imported in import foo from 'some-project' would depend on the file type.

The AssemblyScript guys are currently discussing how to make Node-style module resolution work, with the idea of an asmain field in package.json similar to main but for AS code, or defaulting to assembly/index.ts when there's no asmain field, because of ambiguity between AS and TS files.

Having an assembly/ folder at the root of a project (IMO) doesn't follow the convention in the web/JS community of having a src folder for sources.

If not allowing custom extensions for this, would the TypeScript team rather add another official extension? Perhaps even official AS types into the mix for such files (i32, i64, f32, etc, instead of just number)?

[Griffork]

Agreed!

I'm using visual studio at the moment and would love to include a couple of files of WASM in order to speed up the processing of a fluid sim I'm working on, but the lack of tooling support is preventing me from doing so.

The support that I'd want is:

• At least having errors reported when I manually press build (better would be compile-on-save support with the typescript language service watching the file for changes). I have no way of doing that currently since I'm using a .tsproj file.
• Having typescript pick up on WASM/AS types for the purposes of type checking with typescript files that interact with the WASM code.

I think the easiest way get typescript to support the first point is the proposal linked above - allow me to specify a node module or custom script to run during the build step, whose errors get surfaced by tsc.
As for the second point, that would require a bit of work on typescript's part. I don't mind if AS or WASM is supported by typescript (I can adapt) but I'd like one of them to be supported.

[DanielRosenwasser]

Accepting WebAssembly input files is probably more compelling long-term since it's a relatively-agnostic output, and is easier to statically analyze. Maybe a separate issue should be opened there, though keep in mind that the wasm API boundaries will almost never be as high-level as one might hope from JavaScript.

[weswigham]

@DanielRosenwasser wasm modules would need to stabilize and ship first, tbh

[weswigham]

If you're using wasm today, and you're using it with rust, I can reccomend using wasm-pack (which utilizes the excellent wasm-bindgen), which should automatically generate declaration files alongside the js+wasm bundle. If you're not using rust and you're using something else... well, your wasm building toolchain really understands the most about your inputs and APIs, and could undoubtedly produce better declarations than what we could from the raw wasm (since it can be built form your original source).

[ExE-Boss]

Well, AssemblyScript also needs #202 for the i32, i64, f32 and other numeric types.

[Griffork]

@weswigham I was under the impression that this issue was opened because there was no toolchain for working with WASM in any form with pure typescript (either as input or output files)? Please if there is something available let me know so I can use it.

Also because I forgot to add it to my first comment; I'm building a pure typescript project (both client and server) in visual studio in .tsproj files. .tsproj files don't support other languages, visual studio package files or running scripts or npm modules before/after or alongside typescript builds, meaning the only way I can get WASM to build and show errors would be for typescript to adopt it itself.

I don't mind if limited support is added experimentally behind a flag until things settle down and I'm happy to provide feedback and bug reports for it (as I have done for regular Typescript). I'm sure the other eager beavers are like myself won't mind breaking changes until things settle down with the spec, particularly since with typescript the breaking changes are usually pretty easy and straight-forwards to fix if you read the release notes (and also you expect them if something's behind a flag).

Lastly I'd like to bring up that shortly after Typescript became public was when the ES6 spec was not stabilised or shipped, but was still supported in a limited manner by Typescript and this did cause breaking changes as the spec changed (as I've been using Typescript since 0.8 I experienced a lot of them first-hand, and it really wans't that bad).. As WASM is an experimental component of Javascript and it has limited support in 4 major browsers I don't see why we can't talk about this now... Unless if the Typescript team isn't planning to or doesn't want to support next-gen Javascript code, then maybe that should be made clear in the blog or website or something so you don't get repeatedly asked to implement features like this?

[weswigham]

First off, wasm is an alternative target to run other languages in the browser if it's easier for them to compile to a lower level intermediate language than to compile to js. It is not output for next gen JS, and never will be. Second, we technically have baseline support for wasm modules; if you're using an experimental runtime that somehow hooks them up - just author a filename.wasm.d.ts and put it alongside filename.wasm - we'll use that as the source of type information for import m from "./filename.wasm". What we don't do is analyze wasm to automatically provide type information for it, and we won't do that yet because both the format and function are still in flux (unlike, say json, which is pretty bog standard). (Across like three different working groups, wasm modules, wasm std library, and wasm js interop are all slowly coming together; there's no real, complete implementation yet, really, so we don't even have a platform to target.) And again, as I was saying earlier, while we could produce rudimentary type information for a wasm module, the API contract generated by the x->wasm compiler you use could be way more detailed, since it can retain things from the original language x (like comments, interfaces, enums, type aliases.... All things we'd never get from raw wasm, since it just exports primitive values and functions with primitive valued arguments). That's why wasm-pack is so great; it can persist so much useful stuff from your rust code into your wasm's associated .d.ts.

Lastly, I'm not particularly familiar with VS build chains, but I thought there was some kind of way to hook up task runner tasks to project lifecycle events, which should essentially allow you to do... Whatever; including trigger an x -> wasm build of some kind.

[Griffork]

I didn't realise web assembly was designed to solely be a compile target for languages other than Javascript, I found out about it when I found out that asm was no longer supported, and I wanted to use asm to get near-native performance for some complex computational logic in Javascript. Most of what I had learned was that WASM was the successor to asm.js, and had assumed that I could write WASM code like I could write asm.js code.

Also I never implied that WASM was next-gen output for javascript, I said it was a part of the next generation of javascript, I said it was an experimental javascript api supported by 4 major browsers that seemed to have no Typescript support. I'd been looking around the web for information and this is the first time I've heard that Typescript actually supports wasm.d.ts files (thank you for that info).

Supporting wasm.d.ts was actually what I was asking for in my second point "Having typescript pick up on WASM/AS types for the purposes of type checking".

As to your last point, I didn't know that functionality existed in Visual Studio, so I tried it out on my .tsproj, and it seems typescript projects (or the typescript compiler - I don't know which) don't support the Task Runner Explorer so I can't hook into the typescript build chain using that.

So my first request is still unresolved. And I still believe the easiest way for the typescript team to support it would be to be to add the ability to specify in the .tsconfig file a script that should be run during compile time, whose errors get passed on through the language service.

[weswigham]

As to your last point, I didn't know that functionality existed in Visual Studio, so I tried it out on my .tsproj, and it seems typescript projects (or the typescript compiler - I don't know which) don't support the Task Runner Explorer so I can't hook into the typescript build chain using that.

Hmm. @minestarks ? Is it a .net project thing? Should it be supported in tsproj?

[minestarks]

.tsproj is not an actual Visual Studio project type that I'm aware of. @Griffork how did you create this project? Is it something you can share? If you are opening it in the Visual Studio IDE it's probably treating the file as a different, supported project type (C# project maybe?), so the various features available are going to change based on that.

[Griffork]

You're right, I was using an .njsproj (I wasn't at my computer when I was writing that). AFAIK .njsproj is the closest thing to being a typescript project type? Is there a requirement to use C# or another language just to do this? My project is pure typescript (server and client) so I'd rather not include another language just for this if I can avoid it.