Assemblyscript: Betrachten Sie eine andere Dateierweiterung als .ts

Dies wäre auch für einen Sprachserver in vscode nützlich!

Dies ist etwas, das wir in Zukunft in Betracht ziehen könnten, aber im gegenwärtigen Zustand, dh ohne unseren eigenen Sprachserver, scheint die Wiederverwendung der Erweiterung .ts das Beste zu sein, was wir vernünftigerweise tun können, um eine gute Entwicklererfahrung zu bieten.

Es gibt jedoch einige Indikatoren, anhand derer Tools bestimmen können, wie AS-Code aussieht

• Wenn es ein tsconfig.json das path/to/std/assembly.json , ist das ein AS-Verzeichnis
• Wenn package.json ein ascMain hat, zeigt dies auf eine AS-Eintragsdatei in einem Verzeichnis mit anderem AS-Code
• Wenn package.json ein asbuild -Skript hat, verweisen seine Indizes auf eine AS-Eintragsdatei
• AS-Code befindet sich normalerweise in assembly/ wenn nicht anders konfiguriert

Dies ist etwas, das wir in Zukunft in Betracht ziehen könnten, aber im gegenwärtigen Zustand, dh ohne unseren eigenen Sprachserver, scheint die Wiederverwendung der Erweiterung .ts das Beste zu sein, was wir vernünftigerweise tun können, um eine gute Entwicklererfahrung zu bieten.

Ich verstehe. Ist es nicht einfach, VS Code anzuweisen, .as -Dateien als TypeScript-Dateien zu behandeln? Ich glaube es ist. Dies scheint eine viel einfachere Möglichkeit zu sein, die Vorteile der statischen Analyse von TypeScript in VS Code oder ähnlichen Editoren zu nutzen und dennoch die Vorteile einer separaten Erweiterung zu nutzen.

Als ich das letzte Mal überprüft habe, dass tsc die unterstützten Dateierweiterungen fest codiert hat, bestand die einzige Möglichkeit, dies zu ändern, darin, eine Verzweigung beizubehalten. Das war ungefähr zur Zeit des ASC-Prototyps, aber ich weiß nicht, ob es sich geändert hat.

Ich denke, es hängt hier davon ab, was Sie mit supported file extensions meinen. TypeScript kompiliert Importpfade mit jeder Dateierweiterung. Die Typprüfung ist das einzige Problem mit Erweiterungen, und ich glaube, dass dies mit einer einfachen VS-Code-Erweiterung nicht allzu schwer zu beheben ist. Tatsächlich glaube ich, dass Deno dies bereits für .ts -Erweiterungen getan hat: https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

Außerdem ist VS Code gerade geöffnet, und ich habe ihn angewiesen, .as -Dateien als TypeScript zu behandeln.

Ich habe gerade AssemblyScript hier integriert: https://github.com/lastmjs/zwitterion

Es klappt! Aber wie gesagt, es hängt davon ab, dass AssemblyScript eine eigene Dateierweiterung hat. Im Moment habe ich mich für .as . Und ich habe ein bisschen mehr mit VS-Code experimentiert. Ich kann ihn anweisen, .as als Indikator für eine TypeScript-Datei zu verwenden, und diese Konfiguration wird gespeichert. Das einzige große Problem, das ich sehe, besteht darin, den statischen TypeScript-Analysator anzuweisen, die Erweiterung .as zuzulassen, aber wie die oben verlinkte Deno-Erweiterung sollte dies meiner Meinung nach nicht zu schwierig sein.

Gibt es hier noch andere Probleme?

Das ActionScript-Problem scheint ein Deal Breaker für .as . Vielleicht .asc ?

Ich persönlich mag es nicht, wenn die Erweiterung mit dem Compiler identisch ist. Ich wünschte, wir könnten Wasm irgendwie integrieren, aber wir können .asm und es ist das einzige, an das ich denken kann.

Auch @dcodeIO , RocketScript wäre .rs ... Wenn wir jetzt den Namen ändern würden, wäre es jedoch an der Zeit. Meine einzige Beschwerde mit dem aktuellen Namen ist, dass es zu viele Silben sind. In Übereinstimmung mit dem Weltraumthema könnten wir Ad Astra oder Arugula (in Großbritannien Rakete genannt) machen.

.rs reserviert von Rust =)

Ich wollte nur darauf hinweisen, dass es dieses Problem auch für meinen Kontext gibt: https://github.com/AssemblyScript/assemblyscript/issues/719

Ich denke auch, dass die Github-Sprachen eine gute Referenz sein würden. Es scheint, als ob ActionScript bereits mit AngelScript in Konflikt steht. Daher ist es möglicherweise am besten, ein Problem mit Github zu eröffnen und zu prüfen, ob AssemblyScript als .as zur Liste hinzugefügt werden kann, da dies anscheinend beliebt ist Möglichkeit?

Wie in fragen wir, ob AssemblyScript sein könnte: .as und .assemblyscript ? 🤔

auch cc @jayphelps, da sie hier einige wirklich gute Einblicke hatten 😄

Hier ist ein kleines Repo, das zeigt, was GitHub aus .as . Kann auch gegabelt werden, um zu sehen, was getan werden muss, damit alles sowohl auf der TS- als auch auf der AS-Seite funktioniert:

https://github.com/dcodeIO/asext

Und ja, RocketScript / .rs war eigentlich mein Versuch, lustig zu sein :)

Außerdem finden Sie hier die Dokumente zum Hinzufügen einer neuen Sprache zum Github Language Detector: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding -a-language 😄

Es wurden jedoch einige Nachforschungen angestellt, und @dcodeIO war korrekt. Es scheint, dass Typescript keine andere Erweiterung als die ausdrücklich unterstützten unterstützt: https://github.com/microsoft/TypeScript/issues/10939

Ich fange an zuzustimmen, ob .as.ts hier am sinnvollsten ist. 🤔

@ torch2424 .as.ts wird von TypeScript auch beim Import nicht unterstützt. Wie ich vor einigen Kommentaren erwähnt habe, hängt es davon ab, was Sie unter Support verstehen. Es scheint, dass AssemblyScript nur Unterstützung für statische Analysen in Editoren wie Visual Studio Code oder Atom benötigt. Ist das richtig? Siehe Denos Lösung zum Zulassen von .ts-Erweiterungen bei TypeScript-Importen: https://github.com/justjavac/vscode-deno/blob/master/README.md Ich kann mir nicht vorstellen, dass es zu schwierig wäre, das Plugin zu teilen Erlaube eine andere Erweiterung und erstelle ein AssemblyScript-Plugin für VS Code.

Welche Unterstützung benötigt TypeScript genau? Der Compiler kann bereits jede Erweiterung verarbeiten, der Typechecker ist das einzige, was Probleme mit Erweiterungen hat, die meiner Meinung nach mit Plugins leicht behoben werden können

Es sieht so aus, als ob die eigentliche Logik zum Beheben der .ts -Erweiterungsfehler hier ist: https://github.com/justjavac/typescript-deno-plugin

AssemblyScript wird irgendwann sowieso einen eigenen Sprachserver brauchen, richtig? Ein Plugin für Redakteure scheint eine natürliche Möglichkeit zu sein, diese Erweiterungsprobleme mit der Typprüfung von TypeScript zu beheben. Ich denke nicht, dass wir uns auf etwas beschränken müssen, das mit .ts endet

@ torch2424 .as.ts wird auch beim Import von TypeScript nicht unterstützt. Wie ich vor einigen Kommentaren erwähnt habe, hängt es davon ab, was Sie unter Support verstehen.

Oh mein schlechtes! Ich habe vermisst, dass ich mich entschuldige!

Welche Unterstützung benötigt TypeScript genau? Der Compiler kann bereits jede Erweiterung verarbeiten, der Typechecker ist das einzige, was Probleme mit Erweiterungen hat, die meiner Meinung nach mit Plugins leicht behoben werden können

Hoppla, vielleicht habe ich mich damals geirrt, ich hatte es nicht versucht, aber das offene Problem gefunden, bei dem die Leute keine anderen Erweiterungen verwenden konnten 😂

AssemblyScript wird irgendwann sowieso einen eigenen Sprachserver brauchen, richtig? Ein Plugin für Redakteure scheint eine natürliche Möglichkeit zu sein, diese Erweiterungsprobleme mit der Typprüfung von TypeScript zu beheben. Ich denke nicht, dass wir uns auf etwas beschränken müssen, das mit .ts endet

Ja, ich denke, das ist richtig, @jtenner hat das erwähnt, und ich denke, sie hätten mehr Hintergrundinformationen dazu.

Aber wenn wir in der tsconfig etwas tun können , so dass eine benutzerdefinierte Erweiterung für Typoskriptdateien verwendet werden kann, wäre es meiner Meinung nach gut, wenn wir mit .as 😄 arbeiten würden

Ich denke, es ist Zeit, dass wir eine neue Ausgabe mit dem TypeScript-Team eröffnen und sie fragen, ob es eine Möglichkeit gibt, sich stattdessen an ihren Sprachserver anzuschließen. Sicherlich muss es einen besseren Weg geben, dies mit der Erweiterung .ts zu tun.

Hier ist ein kleines Repo, das zeigt, was GitHub aus .as . Kann auch gegabelt werden, um zu sehen, was getan werden muss, damit alles sowohl auf der TS- als auch auf der AS-Seite funktioniert:

https://github.com/dcodeIO/asext

Und ja, RocketScript / .rs war eigentlich mein Versuch, lustig zu sein :)

Dies ist ein AngelScript nach Github: D.

@dcodeIO übrigens, ich kann dein Repo nicht kompilieren.

Ich kompiliere dieses AngelScript irgendwie so: D.

cd wasm && mv main.as f.ts && asc f.ts -b main.wasm -O3 --runtime none; mv f.ts main.as

.as ist gut, aber Sie sagen ... es steht im Widerspruch zu ActionScript? Mann, ich habe es vor Äonen benutzt. Macromedia ist tot. Adobe Flash ist tot, Flex ist tot. ActionScript ist also auch tot. +1 für .as Name. Gibt es eine Abstimmung?

Übrigens ist es eine coole Bewegung: js -> ts -> as

(Außerdem wäre es cool, AssemblyScript als Obermenge von TypeScript und nicht als Teilmenge zu verwenden.)

Ich stimme zu, .as rundum scheint die beste, natürlichste und bequemste Wahl zu sein, außer bei Konflikten mit anderen Sprachen. Ich denke, wenn es überhaupt möglich ist, wenn wir .as irgendwie zum Laufen bringen können, dann sollten wir es tun. Wenn die anderen Sprachen tot sind oder sterben, erscheint es vernünftig, dass AssemblyScript versucht, die Erweiterung großartig zu machen.

Der Wechsel zu .as ist ein sehr schwieriger Prozess. Wir könnten von GitHub (Github / Linguist) genehmigt werden. Die Sprache sollte dafür ziemlich ausgereift sein. Außerdem muss eine Vielzahl von Editoren und IDEs aktualisiert werden.

@ MaxGraey ja, das stimmt. Und überall in den Dokumenten, Beispielen usw. - überall sollte .as werden - ist das wahrscheinlich der schwierigste Teil.

Das Hervorheben in VSCode ist sehr einfach zu beheben:

// settings.json
{
  "files.associations": {
    "*.as": "typescript"
  }
}

Idealerweise sollte es jedoch nicht von den Einstellungen jeder Person verwaltet werden. Wahrscheinlich sollte es sich um ein separates Plugin handeln, das automatisch vorgeschlagen wird, sobald Sie die Datei .as zum ersten Mal öffnen - viel benutzerfreundlicher als die manuelle Konfigurationsverwaltung. Oder sogar PR in ein vorhandenes TS-Plugin zu verwandeln, um .as als Typoskript zu zählen ... Sind sie syntaktisch äquivalent?

Hallo!

Wir hatten eine Diskussion zu diesem Problem unter https://github.com/AssemblyScript/meta/issues/19

Der wichtigste umsetzbare Gegenstand, den wir daraus gezogen haben, war:

Wir brauchen eine Liste von Dingen, die die Sprache tun müsste, um Unterstützung in den meisten wichtigen IDEs sowie in Github zu erhalten.

Da AssemblyScript die Erweiterung .ts huckepack genommen hat, müssen wir die gesamte Infra erstellen, um unseren eigenen Erweiterungsnamen zu unterstützen. Wie kommen wir zum Beispiel zum Lithist Github Repo, wie bekommen wir Visual Studio Code Support?

Sobald wir das haben, können wir es in Probleme aufteilen. Und dann können wir uns für einen endgültigen Namen entscheiden, unter dem die Leute diese Themen aufgreifen und mit der Implementierung beginnen können.

In der wöchentlichen Besprechung wurden andere Namen vorgeschlagen (mein neuer Favorit ist .asms (Asm Script)), und ja! 😄

PS Wenn wir sicher sind, dass wir den Erweiterungsnamen ändern möchten, ist es viel besser, dies jetzt als später zu tun. Der Grund dafür ist, dass es für alle Menschen schwieriger sein wird, die Namen der Erweiterungen zu ändern, je mehr Menschen AS einführen.

Wie wäre es mit .at (erster und letzter Buchstabe von AssemblyScript)?

.as (Konflikte mit 2 anderen Sprachen auf GitHub)
.at
.ast
.asc (Konflikte mit 3 anderen Sprachen auf GitHub)
.asmt
.asmc
.asms
.asmst
.asmscript
.assemblyscript

.as ist meine erste Wahl ohne Berücksichtigung widersprüchlicher Sprachen, dann .at und .asms . Ich mag die Idee einer Erweiterung mit zwei Buchstaben, weil sie mit dem Erbe der beliebtesten JS-basierten Sprachen, .js und .ts . Wenn wir mehr als zwei Buchstaben schreiben müssen, mag ich .asms wirklich. .ast könnte mit abstrakten Syntaxbäumen verwechselt werden, und die anderen sind nur seltsamer als ich vielleicht möchte.

Es sieht so aus, als ob .at eine sehr verfügbare Erweiterung ist, keine Sprachen, die ich finden kann, und fast keine Dateiformate, vielleicht eines, aus einigen schnellen Google-Suchen.

Hier ist eine generierte Liste mit einer Vielzahl von Möglichkeiten, um Inspiration zu erhalten:

.ac
.ae
.ai
.al
.am
.ap
.ar
.as
.at
.ay
.abc
.abi
.abl
.abp
.abr
.abs
.abt
.aby
.aci
.acp
.acr
.act
.aeb
.aec
.aei
.ael
.aem
.aep
.aer
.aes
.aet
.aey
.aip
.ait
.alc
.ali
.alp
.alr
.als
.alt
.aly
.amb
.amc
.ami
.aml
.amp
.amr
.ams
.amt
.amy
.apt
.ari
.arp
.art
.asb
.asc
.ase
.asi
.asl
.asm
.asp
.asr
.ass
.ast
.asy
.ayc
.ayi
.ayp
.ayr
.ays
.ayt
.abci
.abcp
.abcr
.abct
.abip
.abit
.ablc
.abli
.ablp
.ablr
.abls
.ablt
.ably
.abpt
.abri
.abrp
.abrt
.absc
.absi
.absp
.absr
.abst
.abyc
.abyi
.abyp
.abyr
.abys
.abyt
.acip
.acit
.acpt
.acri
.acrp
.acrt
.aebc
.aebi
.aebl
.aebp
.aebr
.aebs
.aebt
.aeby
.aeci
.aecp
.aecr
.aect
.aeip
.aeit
.aelc
.aeli
.aelp
.aelr
.aels
.aelt
.aely
.aemb
.aemc
.aemi
.aeml
.aemp
.aemr
.aems
.aemt
.aemy
.aept
.aeri
.aerp
.aert
.aesc
.aesi
.aesp
.aesr
.aest
.aeyc
.aeyi
.aeyp
.aeyr
.aeys
.aeyt
.aipt
.alci
.alcp
.alcr
.alct
.alip
.alit
.alpt
.alri
.alrp
.alrt
.alsc
.alsi
.alsp
.alsr
.alst
.alyc
.alyi
.alyp
.alyr
.alys
.alyt
.ambc
.ambi
.ambl
.ambp
.ambr
.ambs
.ambt
.amby
.amci
.amcp
.amcr
.amct
.amip
.amit
.amlc
.amli
.amlp
.amlr
.amls
.amlt
.amly
.ampt
.amri
.amrp
.amrt
.amsc
.amsi
.amsp
.amsr
.amst
.amyc
.amyi
.amyp
.amyr
.amys
.amyt
.arip
.arit
.arpt
.asbc
.asbi
.asbl
.asbp
.asbr
.asbs
.asbt
.asby
.asci
.ascp
.ascr
.asct
.aseb
.asec
.asei
.asel
.asem
.asep
.aser
.ases
.aset
.asey
.asip
.asit
.aslc
.asli
.aslp
.aslr
.asls
.aslt
.asly
.asmb
.asmc
.asmi
.asml
.asmp
.asmr
.asms
.asmt
.asmy
.aspt
.asri
.asrp
.asrt
.assb
.assc
.asse
.assi
.assl
.assm
.assp
.assr
.asss
.asst
.assy
.asyc
.asyi
.asyp
.asyr
.asys
.asyt
.ayci
.aycp
.aycr
.ayct
.ayip
.ayit
.aypt
.ayri
.ayrp
.ayrt
.aysc
.aysi
.aysp
.aysr
.ayst

Fwiw, ich bevorzuge .as , hauptsächlich aus ästhetischen Gründen ( .js , .ts , _A_ssembly_S_cript). Ich hätte gerne einen Sprachserver, der ihn vor dem Wechsel richtig nutzt.

.as lässt mich sofort an ActionScript denken, und es gibt bereits VSCode-Erweiterungen dafür.

Ich würde .asms oder .ascr bevorzugen.

Bisher hat jeder .a* für eine Erweiterung erwähnt, aber wäre .ts* offen (wie .tsas oder .tsa ), da es von TS abzweigt?

Es gibt auch .was (der Schritt vor .wasm ), aber das könnte bereits existieren

Es gibt auch nur .ax oder etwas, das kein direktes Akronym ist.

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Nächste Schritte? Ich will nur nicht, dass das abgestanden wird

Oder benennen Sie das Assembly-Skript einfach in das etwas aussagekräftigere WASM-Skript um und verwenden Sie 'wass', um WASM, WAST, WASI, WAT usw. zu ergänzen.

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Nicht abgestanden. Wie kann eine Entscheidung getroffen werden?

@lastmjs In der letzten Sitzung erwähnte Saul Cabrera, dass sie mit der Arbeit an einem Sprachserver beginnen würden: smile:

Sobald wir das haben, wird dies dieses Problem erheblich lösen, da wir etwas haben werden, das die Assemblyscript-Syntax erkennt und es uns ermöglicht, Plugins und Dinge für die Sprache in anderen Tools und dergleichen zu schreiben: smile:

Auf diese Weise müssen wir uns nicht auf das Typoskript-Tool verlassen, um diese Arbeit für uns zu erledigen, und wir können den Namen der Dateierweiterung von .ts ändern: smile:

Ich bin froh, dass dieses Thema etwas Aufmerksamkeit erhält. Meine 2 Cent: .as ist die intuitivste Erweiterung von AssemblyScript, ähnlich wie .js , .ts . Ich bin gespannt auf die Arbeit auf einem Lang-Server. Dies wird einen großen Beitrag zur Entwicklererfahrung leisten. Tolle Arbeit alle.

+1 für .as .
Sie müssen sich keine Sorgen über den Konflikt mit älteren Sprachen machen. Sie werden irgendwann verblassen.
Tolle Arbeit, übrigens.

Ich bin jetzt im Erweiterungslager. Dies ist wahrscheinlich die willkürlichste Entscheidung, die getroffen werden muss, aber sie sollte getroffen werden.

@dcodeIO Wir haben eine korrekte Syntaxhervorhebung, die mit einer vscode-Erweiterung arbeitet, und eine Entscheidung darüber sollte, wenn möglich, bald erfolgen.

In der Zwischenzeit werde ich einen Großteil meiner Zeit darauf verwenden, die lang erwartete und begehrte AssemblyScript-Erweiterung mit der Dateierweiterung .asc . Dank der compileString() -Methode spielt es keine Rolle, welche Erweiterungen wir verwenden, obwohl sie vom Compiler selbst standardisiert werden sollten und mit einer fehlerhaften Version des Compilers geliefert werden.

Vielleicht sollte ein RFC im AssemblyScript/meta Repo eröffnet werden.

CC @ torch2424 @willemneal und @MaxGraey

@jtenner Dope: smile: Ja,

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn keine weitere Aktivität stattfindet. Vielen Dank für Ihre Beiträge.

Nicht abgestanden! Wie läuft diese Entscheidung?

Wir warten immer noch darauf, dass ich asconfig beende und ich glaube, dass das Flag --extension mit 0.10 ausgeliefert wird. Ist das richtig, @dcodeIO?

Ja, die Flagge landete mit 0.10.0. Die Verwendung ist beispielsweise --extension .as und ersetzt im Wesentlichen alle .ts durch .as . Beachten Sie jedoch, dass asc derzeit jeweils genau eine Erweiterung versteht, was sehr wahrscheinlich zu Problemen mit externen Bibliotheken führt, die eine andere verwenden. Eher ein experimentelles Feature zum Ausprobieren.

@dcodeIO Oh wow! Ich hatte keine Ahnung, dass gelandet war! Tolle Arbeit daran! : smile :: +1:

Für einfaches Projekt in einer Datei funktioniert, danke! Und die Syntax wird jetzt hervorgehoben.
Aber mit Dingen wie rollup-plugin-assemblyscript ist das nicht.

Bearbeiten: Ich habe herausgefunden, wie man dieses Plugin repariert, dessen Version veraltet ist. PR: https://github.com/surma/rollup-plugin-assemblyscript/pull/3