Consider a file extension other than .ts

[lastmjs]

Hi,

I'm the author of Zwitterion, and I'm currently attempting to add support for AssemblyScript. Zwitterion's goal is to allow transpiling (to JS) or compiling (to Wasm) any language for front-end browser development. Languages are detected based on their file extension. This is very simple and allows Zwitterion to differentiate between JavaScript (.js), TypeScript (.ts), Rust (.rs), Wasm (.wasm), etc.

AssemblyScript not having its own file extension makes this rather difficult. Now, besides that use case, I think there are many other reasons why having a separate file extension for AssemblyScript makes sense. Static analysis tools and developer understanding come to mind. The ES modules spec allows for arbitrary file extensions, so this should not be a problem there. Though there is controversy over these issues, I personally think it's clear that any extension should be allowed in a module path. Deno.js has dealt with these issues, I believe creating a VS Code plugin that allows for .ts extensions (it just stops the type error). That may have changed recently, but they've been thinking this through as well.

Sorry for rambling. I hope a separate file extension for AssemblyScript will be considered. Thanks!

[jtenner]

This would be useful for a language server in vscode too!

[dcodeIO]

This is something we might consider in the future, but at the current state, that is without our own language server, reusing the .ts extension appears to be the best we can reasonably do to provide a good dev experience.

There are a couple of indicators, though, that tools can use to determine what's AS code, like

• If there's a tsconfig.json extending path/to/std/assembly.json, that's an AS directory
• If package.json has an ascMain, that's pointing at an AS entry file inside of a directory with other AS code
• Similarly, if package.json has an asbuild script, its subscripts point at an AS entry file
• AS code usually lives in assembly/ if not configured otherwise

[lastmjs]

This is something we might consider in the future, but at the current state, that is without our own language server, reusing the .ts extension appears to be the best we can reasonably do to provide a good dev experience.

I understand. Though, isn't it simple to instruct VS Code to treat .as files as TypeScript files? I believe it is. Seems like that would be a much simpler way to get the benefits of TypeScript's static analysis in VS Code or similar editors, and still get the benefits of having a separate extension.

[dcodeIO]

Last time I checked tsc hard coded the supported file extensions and the only way to change it was to maintain a fork. That was around the time of the asc prototype, though, don't know if it changed.

[lastmjs]

I think it depends here on what you mean by supported file extensions. TypeScript will compile import paths with any file extension. The type checker is the only thing that has problems with extensions, and I believe that isn't too hard to fix with a simple VS Code extension. In fact, I believe Deno has already done this for .ts extensions: https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

Also, I have VS Code open right now, and I instructed it to treat .as files as TypeScript.

[lastmjs]

I just integrated AssemblyScript here: https://github.com/lastmjs/zwitterion

It works! But, like I said, it depends on AssemblyScript having its own file extension. For now I've chosen to go with .as. And I've experimented with VS Code a little more, I can instruct it to use .as as an indicator of being a TypeScript file, and it will save that configuration. The only major problem I see is instructing the TypeScript static analyzer to allow the .as extension, but like that Deno extension I linked to above, I don't think this should be too difficult.

Are there other issues here?

[lastmjs]

Seems the ActionScript problem is a deal breaker for .as. Maybe .asc?

[willemneal]

Personally don't like the idea of the extension being the same as the compiler. I wish we could incorporate Wasm somehow, but we can't use .asm and it's the only one I can think of.

Also @dcodeIO, RocketScript would be .rs... However, if we were to change the name now would be the time. My one complaint with the current name is that it's too many syllables. Keeping with the space theme we could do Ad Astra, or Arugula (which is called rocket in the UK).

[MaxGraey]

.rs reserved by Rust =)

[torch2424]

Just wanted to bring up that there is this issue as well for my context: #719

Also, I think the Github Languages woulld be a good reference. Seems like ActionScript is already conflicting with AngelScript, thus, maybe our best bet here to move forward is open an issue with Github and see if AssemblyScript could be added to the list as .as, as that seems to be the popular option?

As in, we ask if AssemblyScript could be: .as and .assemblyscript? 🤔

also, cc @jayphelps as they had some really good insight here 😄

[dcodeIO]

Here's a little repo showing what GitHub would make of .as. Can also be forked to see what needs to be done to make everything work both on the TS and the AS side:

https://github.com/dcodeIO/asext

And yeah, RocketScript/.rs was actually me trying to be funny :)

[torch2424]

Also, here are the docs for adding a new language to the Github Language detector thing: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding-a-language 😄

However, did some research, and @dcodeIO was correct it seems that, Typescript does not support any extension other than the ones they explicitly support: microsoft/TypeScript#10939

I'm starting to agree with maybe .as.ts makes the most sense here? 🤔

[lastmjs]

@torch2424 .as.ts is not supported by TypeScript in imports either. Like I mentioned a few comments ago, it depends on what you mean by support. It seems the only support AssemblyScript needs is static analysis support in editors like Visual Studio Code or Atom. Is this correct? See Deno's solution to allowing .ts extensions in TypeScript imports: https://github.com/justjavac/vscode-deno/blob/master/README.md I don't imagine it would be too difficult to fork and extend the plugin to allow another extension, creating an AssemblyScript plugin for VS Code.

Exactly what kind of support is needed from TypeScript? The compiler can already handle any extension, the typechecker is the only thing that has issues with extensions, which I imagine is easily fixed with plugins

[lastmjs]

It looks like the actual logic for fixing the .ts extension errors is here: https://github.com/justjavac/typescript-deno-plugin

AssemblyScript will need its own language server eventually anyway, correct? Seems like a plugin for editors could be a natural way to fix these extension issues with the TypeScript type checker. I don't think we need to limit ourselves to something that ends with .ts