Is there any intelligent code hint plugins for webstorm or vscode?

[lowesyang]

A better code hint maybe improve the experience for developing assemblyscript~

[willemneal]

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]

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.

[MaxGraey]

try use this:

/// <reference path="../node_modules/assemblyscript/index.d.ts" />

[jtenner]

FWIW I have a few comments here.

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

function cast<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:

function cast<T extends number>(value: i32): T {
  return <T>value;
}

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.

Example 2: Type Annotations

@external("my", "imported", "function")
declare function imported_function(): void;

This results in...

Decorators are not valid here.ts(1206)

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.

[vgrichina]

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

The question is how do you differentiate between code written for assemblyscript and code written in typescript?

[vgrichina]

The question is how do you differentiate between code written for assemblyscript and code written in typescript?

There is tsconfig.json for that.

[stale]

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]

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]

Well, differentiating between the different int types depends on microsoft/TypeScript#202.

[dcodeIO]

Interesting that this has actually be discussed at TypeScript. Not too optimistic that this'll ever happen, though. My expectation at this point is that we'll have to create our own language service eventually, possibly switching to an .as extension.

[stale]

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]

Is there a way to tell @stale[bot] not to close an issue?

[dcodeIO]

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?

[trusktr]

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]

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]

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.

[onionhammer]

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]

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)

[dcodeIO]

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.