Consider a file extension other than .ts #1003
Comments
|
This would be useful for a language server in vscode too! |
|
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
|
I understand. Though, isn't it simple to instruct VS Code to treat |
|
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. |
|
I think it depends here on what you mean by Also, I have VS Code open right now, and I instructed it to treat |
|
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 Are there other issues here? |
|
Seems the ActionScript problem is a deal breaker for |
|
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 Also @dcodeIO, RocketScript would be |
|
|
|
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 in, we ask if AssemblyScript could be: also, cc @jayphelps as they had some really good insight here 😄 |
|
Here's a little repo showing what GitHub would make of https://github.com/dcodeIO/asext And yeah, RocketScript/ |
|
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 |
|
@torch2424 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 |
|
It looks like the actual logic for fixing the 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 |
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 |
|
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 |
This is an AngelScript according to Github :D |
|
@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 |
|
Btw, it's cool movement: js -> ts -> as (Also, it would be cool AssemblyScript to be a superset of TypeScript, not a subset) |
|
I agree, |
|
Changing to |
|
@MaxGraey yes, that's true. And everywhere in the docs, examples, etc. - everywhere should be mentioned 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 |
|
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 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 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. |
|
How about |
|
It looks like |
|
Here's a generated list of a ton of possibilities to aid in inspiration: Expand to see full extension list
|
|
Fwiw, I'm favoring |
|
I would favor |
|
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. |
|
Not stale. How can a decision be made? |
|
@lastmjs In the last meeing Saul Cabrera mentioned thye were going to start work on a language server 😄 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 😄 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 |
|
I'm glad this issue is getting some attention. My 2 cents: |
|
+1 for |
|
I'm in the as extension camp now. This is probably the most arbitrary decision to make, but it should be made. |
|
@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 Perhaps an RFC should be opened up in the CC @torch2424 @willemneal and @MaxGraey |
|
@jtenner Dope 😄 Yes feel free to open an RFC and link it here! 😄 🎉 |
|
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. |
|
Not stale! How's that decision going? |
|
We are still waiting on me to finish asconfig and I believe the --extension flag shipped with 0.10. Is that right, @dcodeIO? |
|
Yes, the flag landed with 0.10.0. Usage is |
|
@dcodeIO Oh wow! I had no clue that had landed! Great work on that! 😄 👍 |
|
For simple project in one file works, thanks! And syntax is highlighted now. Edit: I figured out how to fix this plugin it has outated version. PR: surma/rollup-plugin-assemblyscript#3 |
|
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. :/ |
|
There are no macros like these, but in case it helps, in AS code there is a constant |
|
@johnnesky I am faced with exactly the same and created an issue #1533 |
|
A problem with current implementation that we can't mix code with |
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!
The text was updated successfully, but these errors were encountered: