You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The .ts extension is the only one recognized currently, but if there's a need for another one, from an AssemblyScript perspective I'd say "why not". Note, though, that adding alternative file extensions to TypeScript (if you'd like to utilize it for example with VSCode for syntax highlighting) appeared to be pretty much impossible without forking it the last time I checked.
Iirc correctly it used to be more complicated than that, perhaps because import statements didn't pick up files with alternative extensions and similar things. If it's somehow possible, though, feel free to investigate further :)
For a bit of additional background: My stance on this so far was to delay this until there's a dedicated language service for AssemblyScript, which in turn is likely to allow picking whatever file extension(s) we'd like.
Yeah, import statements don't seem to work for .as extensions. Though, they do work for .tsx extensions.
btw, the reason for the question in the first place is that I'm trying to create a project that has both AS and TS files, and I'm trying to figure out what's the best way to clearly separate them.
I do the same - but I wanted to have a single TS file with loader code etc. per module. The way I decided to do this is by using .as.ts as file extension for my AS files and then telling TS compiler to ignore any files that end with .as.ts. So, my directory structure looks something like this:
Activity
dcodeIO commentedon Jul 19, 2019
The
.tsextension is the only one recognized currently, but if there's a need for another one, from an AssemblyScript perspective I'd say "why not". Note, though, that adding alternative file extensions to TypeScript (if you'd like to utilize it for example with VSCode for syntax highlighting) appeared to be pretty much impossible without forking it the last time I checked.bobbinth commentedon Jul 19, 2019
I think you can make it kind of work in VS Code:
First, set file association settings like so:
Then instead of relying on
tsconfig.jsonfile, use///directives at the top of.asfiles like so:dcodeIO commentedon Jul 19, 2019
Iirc correctly it used to be more complicated than that, perhaps because
importstatements didn't pick up files with alternative extensions and similar things. If it's somehow possible, though, feel free to investigate further :)For a bit of additional background: My stance on this so far was to delay this until there's a dedicated language service for AssemblyScript, which in turn is likely to allow picking whatever file extension(s) we'd like.
bobbinth commentedon Jul 19, 2019
Yeah,
importstatements don't seem to work for.asextensions. Though, they do work for.tsxextensions.btw, the reason for the question in the first place is that I'm trying to create a project that has both AS and TS files, and I'm trying to figure out what's the best way to clearly separate them.
dcodeIO commentedon Jul 19, 2019
What I've been doing so far is to have two source directories, both with their own tsconfig.json. For example
assembly/for AS andsrc/for TS.bobbinth commentedon Jul 20, 2019
I do the same - but I wanted to have a single TS file with loader code etc. per module. The way I decided to do this is by using
.as.tsas file extension for my AS files and then telling TS compiler to ignore any files that end with.as.ts. So, my directory structure looks something like this:I'm closing this issue since I don't need it any more, and this is probably better addresses as a part of a bigger issue (e.g. #390).
munrocket commentedon Dec 2, 2019
@dcodeIO Bump! Can we create support for optional extensions for full file names?
ivanjeremic commentedon Jan 16, 2021
I follow the discussion around the extension now a bit longer and I want to suggest a total rebrand from AssemblyScript to binode.