Repository navigation
Consider a file extension other than .ts #1003
Description
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!
Activity
jtenner commentedon Dec 12, 2019
This would be useful for a language server in vscode too!
dcodeIO commentedon Dec 12, 2019
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
tsconfig.jsonextendingpath/to/std/assembly.json, that's an AS directorypackage.jsonhas anascMain, that's pointing at an AS entry file inside of a directory with other AS codepackage.jsonhas anasbuildscript, its subscripts point at an AS entry fileassembly/if not configured otherwiselastmjs commentedon Dec 12, 2019
I understand. Though, isn't it simple to instruct VS Code to treat
.asfiles 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 commentedon Dec 12, 2019
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 commentedon Dec 12, 2019
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.tsextensions: https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-denoAlso, I have VS Code open right now, and I instructed it to treat
.asfiles as TypeScript.lastmjs commentedon Dec 13, 2019
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.asas 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 commentedon Dec 18, 2019
Seems the ActionScript problem is a deal breaker for
.as. Maybe.asc?willemneal commentedon Dec 18, 2019
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
.asmand 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 doAd Astra, orArugula(which is called rocket in the UK).MaxGraey commentedon Dec 18, 2019
.rsreserved by Rust =)torch2424 commentedon Dec 18, 2019
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:
.asand.assemblyscript? 🤔also, cc @jayphelps as they had some really good insight here 😄
dcodeIO commentedon Dec 18, 2019
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/
.rswas actually me trying to be funny :)torch2424 commentedon Dec 18, 2019
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.tsmakes the most sense here? 🤔lastmjs commentedon Dec 19, 2019
@torch2424
.as.tsis 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 commentedon Dec 19, 2019
It looks like the actual logic for fixing the
.tsextension errors is here: https://github.com/justjavac/typescript-deno-pluginAssemblyScript 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
.tstorch2424 commentedon Dec 20, 2019
Oh my bad! I missed that my apologies!
Oops, maybe I was wrong then, I hadn't tried it, but found that open issue in which people couldn't use other extensionss 😂
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😄35 remaining items
jtenner commentedon May 16, 2020
We are still waiting on me to finish asconfig and I believe the --extension flag shipped with 0.10. Is that right, @dcodeIO?
dcodeIO commentedon May 16, 2020
Yes, the flag landed with 0.10.0. Usage is
--extension .asfor example, essentially replacing any.tswith.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 commentedon May 18, 2020
@dcodeIO Oh wow! I had no clue that had landed! Great work on that! 😄 👍
munrocket commentedon Oct 28, 2020
For simple project in one file works, thanks! And syntax is highlighted now.
But with things like
rollup-plugin-assemblyscriptis not.Edit: I figured out how to fix this plugin it has outated version. PR: surma/rollup-plugin-assemblyscript#3
johnnesky commentedon Dec 13, 2020
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 commentedon Dec 13, 2020
There are no macros like these, but in case it helps, in AS code there is a constant
ASC_TARGETthat is1when compiling to Wasm, respectively0when 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 addsglue/jsrespectivelyglue/wasmdepending on the target. (I also like the idea of falling back to.tseventually, though.)munrocket commentedon Dec 13, 2020
@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 commentedon Jun 8, 2021
A problem with current implementation that we can't mix code with
.asand.tsEven if you trying to test
.ascode you will get troubles https://github.com/jtenner/as-pect/issues/355danon commentedon Jul 26, 2024
Is the idea of AssemblyScript being a superset/subset of TypeScript still current? Doesn't it seam like an unnecessary dependency?
PS: Hack developed by facebook was initially supposed to be fully compatbile with PHP, but they divereged since. Wouldn't the same happen with AS eventually?
HerrCai0907 commentedon Jul 28, 2024
I partially agree this idea. From my perspective, I think it is in language design side that AS is subset of TS. I hope the TS dev can easily port to AS in half hour instead of learning a new language.
PaperPrototype commentedon Nov 14, 2025
What was the reasoning behind going with “.as” when it conflicts with action script and angel script? What about “.ass” short for assembly?
PaperPrototype commentedon Nov 14, 2025
Or even “.asss” for assembly script
JairusSW commentedon Nov 14, 2025
That's pretty ass 🍑
PaperPrototype commentedon Nov 15, 2025
I mean 😂 it could help with media coverage ¯\(ツ)/¯
Also increases the languages memeification, which is always a bonus