Handling AssemblyScript input files

(Continuing from https://github.com/Microsoft/TypeScript/issues/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)?

[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.

[trusktr]

@Griffork Can you use VS Code instead? It is designed to work with TypeScript out of the box.

It would be also nice if TypeScript from the box will be able to compile to WebAssembly and handle .ts and .as files

TypeScript’s goal is to provide types on top of JavaScript, and so far that is all.

If you use AssemblyScript, then you are already writing TypeScript code (make sure you use the compatible features), and TypeScript will already generate declaration file output. Then you can use another tool, like Webpack with a loader, to import directly from a .ts that is for example in an assembly/ folder. I recommend to discuss how to do this on AssemblyScript’s Discord chat server: https://discord.gg/U63XU2J

This issue is suggesting maybe supporting a new file type, which could make it easier to organize code. Also this pull request could help make the AssemblyScript number types easier to work with in VS Code (or any editor supporting TS).