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: https://github.com/AssemblyScript/assemblyscript/issues/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: https://github.com/microsoft/TypeScript/issues/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

[torch2424]

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

Oh my bad! I missed that my apologies!

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

Oops, maybe I was wrong then, I hadn't tried it, but found that open issue in which people couldn't use other extensionss 😂

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

Yeah I think that' correct, @jtenner mentioned this, and I think they'd have more background on it.

But, if we can do ssomething in the tsconfig, such that it can use a custom extension for typescript files, I think it'd be good if we went with .as 😄

[jtenner]

I think it's time we opened a new issue with the TypeScript team and ask them if there's a way to hook into their language server instead? Surely there must be a better way to do this with the .ts extension.

[munrocket]

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 :)

This is an AngelScript according to Github :D

[munrocket]

@dcodeIO by the way, I can't compile your repo.

I am compile this AngelScript somehow like that :D

cd wasm && mv main.as f.ts && asc f.ts -b main.wasm -O3 --runtime none; mv f.ts main.as

[jerrygreen]

.as is good but you say... it's conflicting with ActionScript? Man, I've used it eons ago. Macromedia is dead. Adobe Flash is dead, Flex is dead. So ActionScript is also dead. +1 for .as name. Is there a voting?

Btw, it's cool movement: js -> ts -> as

(Also, it would be cool AssemblyScript to be a superset of TypeScript, not a subset)

[lastmjs]

I agree, .as all around seems like the best, most natural, most comfortable choice, except for conflicts with other languages. I think if at all possible, if we can somehow make .as work, then we should. If the other languages are dead or dieing, seems reasonable that AssemblyScript should have a shot at making the extension great.

[MaxGraey]

Changing to .as is really hard process. We could get approve from GitHub (github/linguist). Language should be quite mature for that. Also need update a wide range of editors & IDEs.

[jerrygreen]

@MaxGraey yes, that's true. And everywhere in the docs, examples, etc. - everywhere should be mentioned .as, - that's probably the hardest part.

It's very easy to fix highlighting in VSCode:

// settings.json
{
  "files.associations": {
    "*.as": "typescript"
  }
}

Though, ideally it shouldn't be managed by each person's settings. Probably should be a separate plugin, which will be automatically suggested once you open .as file for first time, - much more user friendly than manual config management. Or even to make PR into existing TS plugin to count .as as typescript... Are they syntactically equivalent?

[torch2424]

Hello!

We had a discussion about this issue in https://github.com/AssemblyScript/meta/issues/19

The main actionable item we got out of it was:

We need a list of things that the language would need to do to get support in most Major IDEs, as well as, Github.

Since AssemblyScript has been piggy-backing off of the .ts extension, this means we need to build all of the infra to support our own extension name. For example, how do we get on the linguist Github repo, how do we get Visual Studio Code Support.

Once we have that, we can break it down into issues. And then we can decide on a final name, in which people can take up those issues, and start the implementation.

There were other names proposed in the Weekly meeting (My new favorite being .asms (Asm Script)), and yeah! 😄

P.S At the same time, if we are certain we want to change the extension name, it is much better to do it now, rather than later. The reason being that as more people adopt AS, the harder it will be for everyone to change the extension names.

[MaxGraey]

How about .at (first and last letter of AssemblyScript)?

[lastmjs]

.as (conflicts with 2 other languages on GitHub) .at .ast .asc (conflicts with 3 other languages on GitHub) .asmt .asmc .asms .asmst .asmscript .assemblyscript

.as is my number one choice without consideration to conflicting languages, then .at and .asms. I like the idea of a two letter extension because it goes along with the heritage of the most popular JS-based languages, .js and .ts. If we have to go more than two letters, I really like .asms. .ast might be confused with Abstract Syntax Trees, and the other ones are just weirder than I might like.

It looks like .at is a very available extension, no languages that I can find, and almost no file formats, maybe one, from some quick Google searches.

[jayphelps]

Here's a generated list of a ton of possibilities to aid in inspiration:

Expand to see full extension list

``` .ac .ae .ai .al .am .ap .ar .as .at .ay .abc .abi .abl .abp .abr .abs .abt .aby .aci .acp .acr .act .aeb .aec .aei .ael .aem .aep .aer .aes .aet .aey .aip .ait .alc .ali .alp .alr .als .alt .aly .amb .amc .ami .aml .amp .amr .ams .amt .amy .apt .ari .arp .art .asb .asc .ase .asi .asl .asm .asp .asr .ass .ast .asy .ayc .ayi .ayp .ayr .ays .ayt .abci .abcp .abcr .abct .abip .abit .ablc .abli .ablp .ablr .abls .ablt .ably .abpt .abri .abrp .abrt .absc .absi .absp .absr .abst .abyc .abyi .abyp .abyr .abys .abyt .acip .acit .acpt .acri .acrp .acrt .aebc .aebi .aebl .aebp .aebr .aebs .aebt .aeby .aeci .aecp .aecr .aect .aeip .aeit .aelc .aeli .aelp .aelr .aels .aelt .aely .aemb .aemc .aemi .aeml .aemp .aemr .aems .aemt .aemy .aept .aeri .aerp .aert .aesc .aesi .aesp .aesr .aest .aeyc .aeyi .aeyp .aeyr .aeys .aeyt .aipt .alci .alcp .alcr .alct .alip .alit .alpt .alri .alrp .alrt .alsc .alsi .alsp .alsr .alst .alyc .alyi .alyp .alyr .alys .alyt .ambc .ambi .ambl .ambp .ambr .ambs .ambt .amby .amci .amcp .amcr .amct .amip .amit .amlc .amli .amlp .amlr .amls .amlt .amly .ampt .amri .amrp .amrt .amsc .amsi .amsp .amsr .amst .amyc .amyi .amyp .amyr .amys .amyt .arip .arit .arpt .asbc .asbi .asbl .asbp .asbr .asbs .asbt .asby .asci .ascp .ascr .asct .aseb .asec .asei .asel .asem .asep .aser .ases .aset .asey .asip .asit .aslc .asli .aslp .aslr .asls .aslt .asly .asmb .asmc .asmi .asml .asmp .asmr .asms .asmt .asmy .aspt .asri .asrp .asrt .assb .assc .asse .assi .assl .assm .assp .assr .asss .asst .assy .asyc .asyi .asyp .asyr .asys .asyt .ayci .aycp .aycr .ayct .ayip .ayit .aypt .ayri .ayrp .ayrt .aysc .aysi .aysp .aysr .ayst ```

[dcodeIO]

Fwiw, I'm favoring .as, mostly for aesthetic reasons (.js, .ts, _A_ssembly_S_cript). Would like to have a language server to make proper use of it before making the switch, though.

[jedisct1]

.as immediately makes me think of ActionScript, and there are VSCode extensions for it already.

I would favor .asms or .ascr.

[DanielRX]

Everyone so far has mentioned .a* for an extentsion, but would .ts* be open (like .tsas or .tsa) since it is branching off from TS?

There is also .was (the step before .wasm) but that might already exist

There's also just going for .ax or something that isn't a direct acronym.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lastmjs]

Next steps? Just don't want this to go stale

[andyherbert]

Or just rename Assembly Script to the slightly more descriptive WASM Script and use 'wass' to complement WASM, WAST, WASI, WAT, etc.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lastmjs]

Not stale. How can a decision be made?

[torch2424]

@lastmjs In the last meeing Saul Cabrera mentioned thye were going to start work on a language server :smile:

Once we have that, that will greatly help drive this issue, since we will have something that recognizes Assemblyscript syntax, and allow us to start writing plugins and things for the language in other tools and such :smile:

That way, we won't have to depend on the typescript tooling to do this work for us, and we can start changing the file extension name from .ts :smile:

[pkieltyka]

I'm glad this issue is getting some attention. My 2 cents: .as is the most intuitive extension of AssemblyScript, as in similar spirit to .js, .ts. I'm excited to hear about work on a lang server too, this will go a long way in the dev experience. Great work all.

[mpmartins]

+1 for .as. No need to worry about the conflict with older languages. They will fade away eventually. Great work, BTW.

[jtenner]

I'm in the as extension camp now. This is probably the most arbitrary decision to make, but it should be made.

[jtenner]

@dcodeIO we have proper syntax highlighting working with a vscode extension, and making a decision about this should happen soon, if possible.

In the meantime, I am going to commit a large majority of my time to develop the long awaited and coveted AssemblyScript extension using the .asc file extension. Thanks to the compileString() method, it won't matter which extensions we use, even though it should be standardized by the compiler itself, and come with a breaking release of the compiler.

Perhaps an RFC should be opened up in the AssemblyScript/meta repo.

CC @torch2424 @willemneal and @MaxGraey

[torch2424]

@jtenner Dope :smile: Yes feel free to open an RFC and link it here! :smile: :tada:

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lastmjs]

Not stale! How's that decision going?

[jtenner]

We are still waiting on me to finish asconfig and I believe the --extension flag shipped with 0.10. Is that right, @dcodeIO?

[dcodeIO]

Yes, the flag landed with 0.10.0. Usage is --extension .as for example, essentially replacing any .ts with .as. Note, however, that asc understands exactly one extension at a time currently, very likely leading to problems with external libraries using a different one. Rather an experimental feature to try things out.

[torch2424]

@dcodeIO Oh wow! I had no clue that had landed! Great work on that! :smile: :+1:

[munrocket]

For simple project in one file works, thanks! And syntax is highlighted now. But with things like rollup-plugin-assemblyscript is not.

Edit: I figured out how to fix this plugin it has outated version. PR: https://github.com/surma/rollup-plugin-assemblyscript/pull/3

[johnnesky]

Hi, I'd like to add a use-case: portability. For the sake of re-using code between AssemblyScript and TypeScript, having the option of using the ".ts" extension is great, it means both compilers can use the same file. However, there are situations where the AssemblyScript code has to be slightly different. In such cases, it would be nice to be able to import, say, "library-name", and let the TypeScript compiler find "library-name.ts" while the AssemblyScript compiler would first look for a specialized version called "library-name.as.ts" or "library-name.as" and fall back on the ".ts" version if available. That would allow the two compilers to mostly share the same code, but load slightly different code where necessary.

Actually what I really want is just compile-time macros, e.g. #ifdef(assemblyscript) ... #else ... #end but sadly neither compiler will support that AFAIK. :/

[dcodeIO]

There are no macros like these, but in case it helps, in AS code there is a constant ASC_TARGET that is 1 when compiling to Wasm, respectively 0 when compiling to JS with the portable stdlib included. When not including the portable stdlib, it's not defined when compiling to JS. Where that's not enough, what I typically do is to add varying entry files. The compiler for example adds glue/js respectively glue/wasm depending on the target. (I also like the idea of falling back to .ts eventually, though.)

[munrocket]

@johnnesky I am faced with exactly the same and created an issue #1533 Probably we should think about this deeper, so I will reopen the issue.

[munrocket]

A problem with current implementation that we can't mix code with .as and .ts Even if you trying to test .as code you will get troubles https://github.com/jtenner/as-pect/issues/355