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
{{ message }}
Repository navigation
Is there any intelligent code hint plugins for webstorm or vscode? #390
vscode has good typescript support and assembly script is still valid typescript. For what it's worth, I use atom and it has type docs and explores type declarations.
Yeah. But the new types provided by assemblyscript like u32, u64 will get error hints in vscode and webstorm. And built-in functions have no code hints.
vscode has good typescript support and assembly script is still valid typescript.
There are plenty of differences between TypeScript and AssemblyScript. It's technically not a perfect subset of TypeScript. The following examples make things a bit clearer.
Example 1: Type Casting
functioncast<T>(value: i32): T{return<T>value;}
In this example we get the following error from the typescript even though this is 100% valid AssemblyScript, as long as the value can technically be cast at compile time.
Conversion of type 'number' to type 'T' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. ts(2352)
I have suggested to @dcodeIO and @MaxGraey that we could use a number type, and they suggested that it might default to f64 so that we can do type extension like this, and quelch the generator error in TypeScript world:
Yeah. But the new types provided by assemblyscript like u32, u64 will get error hints in vscode and webstorm. And built-in functions have no code hints.
Yep. When using vscode, for instance, whenever I use a type backed by number, there are no code hints for converting between the number types. All numbers are treated like f64 in the ide regardless of strict typing in AssemblyScript. In order to fix a problem like this, we would need to adopt a new file extension and create language a support extension just for AssemblyScript in vscode. Syntax highlighting can be offset onto the TypeScript syntax highlighting, obviously.
Of course, annotations don't belong on function declarations, or on inline functions. They usually only appear on class members to modify the class prototype. This is because TypeScript is guided by the ecmascript specification, wheras AssemblyScript has it's own parser/compiler combo and has a great use-case for annotations like @inline and @operator that might not appear on class members.
I think there is a great use case for creating an AssemblyScript plugin for ides, but that should definitely be discussed in a RFC thread.
Reacted by wang.hanbin, Vladimir Grichina, ExE Boss, Maximilian Hofmann, Nathan Handmade and Daniel Wilkowski
@jtenner I think making some patches to https://github.com/Microsoft/monaco-typescript is going to give biggest bang for buck.
There are likely only small changes needed (to ignore some warnings) and it's going to cover VSCode + variety of web IDEs using Monaco.
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.
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.
It's currently configured to automatically mark issues without further activity as stale and close them after a while if no new activity happens, unless tagged as enhancement, bug or likewise. So far I considered this issue a question, but looks its more of an enhancement request now?
Ah, true, it won't compile anyways. So looks like the trick of putting those imports in a separate file (like in #384 (comment)) may be the way to do it.
I will also look at exporting getFour from a module. Then maybe a Babel or Gulp step before asc can supply the @external code.
in some parts it's stricter subset (no any and undefined, no dynamic properties, nominal type system) in some part it's superset (more integer and float types, operator overloading, builtin decorators over functions and declarations and etc)
Reacted by ExE Boss, munrocket and Nathan Handmade
Closing this issue as part of 2020 vacuum because it is more a question, with a solution being discussed elsewhere as part of creating a custom language server.
Activity
willemneal commentedon Dec 26, 2018
vscode has good typescript support and assembly script is still valid typescript. For what it's worth, I use atom and it has type docs and explores type declarations.
lowesyang commentedon Dec 27, 2018
Yeah. But the new types provided by assemblyscript like
u32,u64will get error hints in vscode and webstorm. And built-in functions have no code hints.MaxGraey commentedon Dec 27, 2018
try use this:
/// <reference path="../node_modules/assemblyscript/index.d.ts" />jtenner commentedon Dec 27, 2018
FWIW I have a few comments here.
There are plenty of differences between TypeScript and AssemblyScript. It's technically not a perfect subset of TypeScript. The following examples make things a bit clearer.
Example 1: Type Casting
In this example we get the following error from the typescript even though this is 100% valid AssemblyScript, as long as the value can technically be cast at compile time.
I have suggested to @dcodeIO and @MaxGraey that we could use a
numbertype, and they suggested that it might default tof64so that we can do type extension like this, and quelch the generator error in TypeScript world:Yep. When using vscode, for instance, whenever I use a type backed by
number, there are no code hints for converting between the number types. All numbers are treated likef64in the ide regardless of strict typing in AssemblyScript. In order to fix a problem like this, we would need to adopt a new file extension and create language a support extension just for AssemblyScript in vscode. Syntax highlighting can be offset onto the TypeScript syntax highlighting, obviously.Example 2: Type Annotations
This results in...
Of course, annotations don't belong on function declarations, or on inline functions. They usually only appear on class members to modify the class prototype. This is because TypeScript is guided by the ecmascript specification, wheras AssemblyScript has it's own parser/compiler combo and has a great use-case for annotations like
@inlineand@operatorthat might not appear on class members.I think there is a great use case for creating an AssemblyScript plugin for ides, but that should definitely be discussed in a RFC thread.
vgrichina commentedon Feb 2, 2019
@jtenner I think making some patches to https://github.com/Microsoft/monaco-typescript is going to give biggest bang for buck.
There are likely only small changes needed (to ignore some warnings) and it's going to cover VSCode + variety of web IDEs using Monaco.
jtenner commentedon Feb 2, 2019
The question is how do you differentiate between code written for assemblyscript and code written in typescript?
vgrichina commentedon Feb 6, 2019
There is
tsconfig.jsonfor that.stale commentedon Mar 9, 2019
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.
stale commentedon Apr 9, 2019
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.
ExE-Boss commentedon Apr 9, 2019
Well, differentiating between the different
inttypes depends on microsoft/TypeScript#202.2 remaining items
ExE-Boss commentedon May 16, 2019
Is there a way to tell @stale[bot] not to close an issue?
dcodeIO commentedon May 16, 2019
It's currently configured to automatically mark issues without further activity as stale and close them after a while if no new activity happens, unless tagged as
enhancement,bugor likewise. So far I considered this issue a question, but looks its more of an enhancement request now?trusktr commentedon May 27, 2019
Is there currently a way to to tell TypeScript (not AssemblyScript) not to complain about
decorators are not valid here?I'm using Atom with the atom-typescript plugin, so that I can get all the IDE features.
dcodeIO commentedon May 27, 2019
We use
// @ts-ignore, which will ignore the next line in AS, but not sure if a missing decorator like that will compile with tsc.trusktr commentedon May 27, 2019
Ah, true, it won't compile anyways. So looks like the trick of putting those imports in a separate file (like in #384 (comment)) may be the way to do it.
I will also look at exporting
getFourfrom a module. Then maybe a Babel or Gulp step beforeasccan supply the@externalcode.onionhammer commentedon Feb 16, 2020
Regarding the @external decorator on declarations; If it's not valid TypeScript, should it be valid AssemblyScript? I thought AS was a subset of TS?
MaxGraey commentedon Feb 16, 2020
in some parts it's stricter subset (no
anyandundefined, no dynamic properties, nominal type system) in some part it's superset (more integer and float types, operator overloading, builtin decorators over functions and declarations and etc)dcodeIO commentedon May 27, 2020
Closing this issue as part of 2020 vacuum because it is more a question, with a solution being discussed elsewhere as part of creating a custom language server.