Assemblyscript: Considérez une extension de fichier autre que .ts

Cela serait également utile pour un serveur de langue dans vscode!

C'est quelque chose que nous pourrions envisager à l'avenir, mais dans l'état actuel, c'est-à-dire sans notre propre serveur de langage, la réutilisation de l'extension .ts semble être le meilleur que nous puissions raisonnablement faire pour offrir une bonne expérience de développement.

Il existe cependant quelques indicateurs que les outils peuvent utiliser pour déterminer ce qu'est le code AS, comme

• S'il y a un tsconfig.json étendant path/to/std/assembly.json , c'est un répertoire AS
• Si package.json a un ascMain , cela pointe vers un fichier d'entrée AS à l'intérieur d'un répertoire avec un autre code AS
• De même, si package.json a un script asbuild , ses indices pointent vers un fichier d'entrée AS
• Le code AS vit généralement dans assembly/ s'il n'est pas configuré autrement

C'est quelque chose que nous pourrions envisager à l'avenir, mais dans l'état actuel, c'est-à-dire sans notre propre serveur de langage, la réutilisation de l'extension .ts semble être le meilleur que nous puissions raisonnablement faire pour offrir une bonne expérience de développement.

Je comprends. Cependant, n'est-il pas simple de demander à VS Code de traiter les fichiers .as comme des fichiers TypeScript? Je le crois. Il semble que ce serait un moyen beaucoup plus simple d'obtenir les avantages de l'analyse statique de TypeScript dans VS Code ou des éditeurs similaires, tout en bénéficiant d'une extension distincte.

La dernière fois que j'ai vérifié tsc, j'ai codé en dur les extensions de fichier prises en charge et le seul moyen de le changer était de maintenir un fork. C'était à l'époque du prototype asc, cependant, je ne sais pas si cela a changé.

Je pense que cela dépend ici de ce que vous entendez par supported file extensions . TypeScript compilera les chemins d'importation avec n'importe quelle extension de fichier. Le vérificateur de type est la seule chose qui a des problèmes avec les extensions, et je pense que ce n'est pas trop difficile à résoudre avec une simple extension VS Code. En fait, je pense que Deno a déjà fait cela pour les extensions .ts : https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

De plus, VS Code est ouvert en ce moment, et je lui ai demandé de traiter les fichiers .as comme TypeScript.

Je viens d'intégrer AssemblyScript ici: https://github.com/lastmjs/zwitterion

Ça marche! Mais, comme je l'ai dit, cela dépend de AssemblyScript ayant sa propre extension de fichier. Pour l'instant, j'ai choisi d'utiliser .as . Et j'ai expérimenté un peu plus VS Code, je peux lui demander d'utiliser .as comme indicateur d'être un fichier TypeScript, et il enregistrera cette configuration. Le seul problème majeur que je vois est de demander à l'analyseur statique TypeScript d'autoriser l'extension .as, mais comme l'extension Deno que j'ai liée ci-dessus, je ne pense pas que cela devrait être trop difficile.

Y a-t-il d'autres problèmes ici?

Il semble que le problème d'ActionScript soit un facteur décisif pour .as . Peut-être .asc ?

Personnellement, je n'aime pas l'idée que l'extension soit la même que le compilateur. J'aurais aimé pouvoir incorporer Wasm d'une manière ou d'une autre, mais nous ne pouvons pas utiliser .asm et c'est le seul auquel je puisse penser.

Aussi @dcodeIO , RocketScript serait .rs ... Cependant, si nous devions changer le nom maintenant, ce serait le moment. Mon seul reproche avec le nom actuel est qu'il contient trop de syllabes. En gardant le thème de l'espace, nous pourrions faire Ad Astra , ou Arugula (qui s'appelle fusée au Royaume-Uni).

.rs réservé par Rust =)

Je voulais juste signaler qu'il existe également ce problème pour mon contexte: https://github.com/AssemblyScript/assemblyscript/issues/719

De plus, je pense que les langues Github seraient une bonne référence. On dirait qu'ActionScript est déjà en conflit avec AngelScript, donc, peut-être que notre meilleur pari ici pour aller de l'avant est d'ouvrir un problème avec Github et de voir si AssemblyScript pourrait être ajouté à la liste en tant que .as , car cela semble être le plus populaire option?

Comme dans, nous demandons si AssemblyScript pourrait être: .as et .assemblyscript ? 🤔

aussi, cc @jayphelps car ils avaient de très bonnes idées ici here

Voici un petit dépôt montrant ce que GitHub ferait de .as . Peut également être bifurqué pour voir ce qui doit être fait pour que tout fonctionne à la fois du côté TS et du côté AS:

https://github.com/dcodeIO/asext

Et oui, RocketScript / .rs était en fait moi essayant d'être drôle :)

Aussi, voici la documentation pour ajouter une nouvelle langue au détecteur de langage Github: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding -a-language 😄

Cependant, après quelques recherches, et @dcodeIO était correct, il semble que Typescript ne prend en charge aucune extension autre que celles qu'ils prennent explicitement en charge: https://github.com/microsoft/TypeScript/issues/10939

Je commence à être d'accord avec peut-être que .as.ts est le plus logique ici? 🤔

@ torch2424 .as.ts n'est pas non plus pris en charge par TypeScript dans les importations. Comme je l'ai mentionné il y a quelques commentaires, cela dépend de ce que vous entendez par soutien. Il semble que la seule prise en charge dont AssemblyScript ait besoin est la prise en charge de l'analyse statique dans les éditeurs tels que Visual Studio Code ou Atom. Est-ce correct? Voir la solution de Deno pour autoriser les extensions .ts dans les importations TypeScript: https://github.com/justjavac/vscode-deno/blob/master/README.md Je n'imagine pas qu'il serait trop difficile de bifurquer et d'étendre le plugin à autoriser une autre extension, en créant un plugin AssemblyScript pour VS Code.

Quel type de support est exactement nécessaire de la part de TypeScript? Le compilateur peut déjà gérer n'importe quelle extension, le vérificateur de type est la seule chose qui a des problèmes avec les extensions, ce qui, j'imagine, est facilement corrigé avec des plugins

Il semble que la logique réelle pour corriger les erreurs d'extension .ts est ici: https://github.com/justjavac/typescript-deno-plugin

AssemblyScript aura de toute façon besoin de son propre serveur de langage, n'est-ce pas? On dirait qu'un plugin pour les éditeurs pourrait être un moyen naturel de résoudre ces problèmes d'extension avec le vérificateur de type TypeScript. Je ne pense pas que nous devons nous limiter à quelque chose qui se termine par .ts

@ torch2424 .as.ts n'est pas non plus pris en charge par TypeScript dans les importations. Comme je l'ai mentionné il y a quelques commentaires, cela dépend de ce que vous entendez par soutien.

Oh mon mauvais! J'ai raté ça mes excuses!

Quel type de support est exactement nécessaire de la part de TypeScript? Le compilateur peut déjà gérer n'importe quelle extension, le vérificateur de type est la seule chose qui a des problèmes avec les extensions, ce qui, j'imagine, est facilement corrigé avec des plugins

Oups, je me suis peut-être trompé alors, je ne l'avais pas essayé, mais j'ai trouvé ce problème ouvert dans lequel les gens ne pouvaient pas utiliser d'autres extensions 😂

AssemblyScript aura de toute façon besoin de son propre serveur de langage, n'est-ce pas? On dirait qu'un plugin pour les éditeurs pourrait être un moyen naturel de résoudre ces problèmes d'extension avec le vérificateur de type TypeScript. Je ne pense pas que nous devons nous limiter à quelque chose qui se termine par .ts

Oui, je pense que `` c'est correct, @jtenner l'a mentionné, et je pense qu'ils auraient plus d'informations à ce sujet.

Mais, si nous pouvons faire quelque chose dans le tsconfig, de sorte qu'il puisse utiliser une extension personnalisée pour les fichiers dactylographiés , je pense que ce serait bien si nous allions avec .as 😄

Je pense qu'il est temps d'ouvrir un nouveau problème avec l'équipe TypeScript et de leur demander s'il existe un moyen de se connecter à leur serveur de langage à la place? Il doit sûrement y avoir une meilleure façon de faire cela avec l'extension .ts .

Voici un petit dépôt montrant ce que GitHub ferait de .as . Peut également être bifurqué pour voir ce qui doit être fait pour que tout fonctionne à la fois du côté TS et du côté AS:

https://github.com/dcodeIO/asext

Et oui, RocketScript / .rs était en fait moi essayant d'être drôle :)

Ceci est un AngelScript selon Github: D

@dcodeIO au fait, je ne peux pas compiler votre repo.

Je compile cet AngelScript en quelque sorte comme ça: D

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

.as c'est bien mais vous dites ... c'est en conflit avec ActionScript? Mec, je l'ai utilisé il y a des siècles. Macromedia est mort. Adobe Flash est mort, Flex est mort. Donc ActionScript est également mort. +1 pour .as nom. Y a-t-il un vote?

Btw, c'est cool mouvement: js -> ts -> as

(De plus, ce serait cool AssemblyScript d'être un sur -

Je suis d'accord, .as tout autour semble être le meilleur choix, le plus naturel et le plus confortable, sauf pour les conflits avec d'autres langues. Je pense que si c'est possible, si nous pouvons d'une manière ou d'une autre faire fonctionner .as , alors nous devrions. Si les autres langages sont morts ou en train de mourir, il semble raisonnable qu'AssemblyScript ait une chance de rendre l'extension géniale.

Changer en .as est un processus vraiment difficile. Nous pourrions obtenir l'approbation de GitHub (github / linguist). La langue doit être assez mature pour cela. Besoin également de mettre à jour un large éventail d'éditeurs et d'IDE.

@MaxGraey oui, c'est vrai. Et partout dans la documentation, les exemples, etc. - partout devrait être mentionné .as , - c'est probablement la partie la plus difficile.

Il est très facile de corriger la mise en évidence dans VSCode:

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

Cependant, idéalement, cela ne devrait pas être géré par les paramètres de chaque personne. Il devrait probablement s'agir d'un plugin séparé, qui sera automatiquement suggéré une fois que vous ouvrez le fichier .as pour la première fois, - beaucoup plus convivial que la gestion manuelle de la configuration. Ou même faire de PR dans le plugin TS existant pour compter .as comme dactylographié ... Sont-ils syntaxiquement équivalents?

salut!

Nous avons eu une discussion sur ce problème dans https://github.com/AssemblyScript/meta/issues/19

Le principal élément exploitable que nous en avons tiré était:

Nous avons besoin d'une liste de choses que le langage devrait faire pour obtenir un support dans la plupart des IDE majeurs, ainsi que dans Github.

Étant donné que AssemblyScript a utilisé l'extension .ts , cela signifie que nous devons construire toutes les infra pour prendre en charge notre propre nom d'extension. Par exemple, comment accéder au référentiel Github du linguiste, comment obtenir la prise en charge de Visual Studio Code.

Une fois que nous avons cela, nous pouvons le décomposer en problèmes. Ensuite, nous pouvons décider d'un nom final, dans lequel les gens peuvent aborder ces questions, et commencer la mise en œuvre.

Il y avait d'autres noms proposés lors de la réunion hebdomadaire (mon nouveau favori étant .asms (Asm Script)), et oui! 😄

PS En même temps, si nous sommes certains de vouloir changer le nom de l'extension, il vaut mieux le faire maintenant plutôt que plus tard. La raison étant que plus de personnes adoptent AS, plus il sera difficile pour tout le monde de changer les noms d'extension.

Que diriez-vous de .at (première et dernière lettre de AssemblyScript)?

.as (conflit avec 2 autres langues sur GitHub)
.at
.ast
.asc (conflit avec 3 autres langues sur GitHub)
.asmt
.asmc
.asms
.asmst
.asmscript
.assemblyscript

.as est mon choix numéro un sans tenir compte des langues conflictuelles, puis .at et .asms . J'aime l'idée d'une extension de deux lettres car elle va de pair avec l'héritage des langages JS les plus populaires, .js et .ts . Si nous devons écrire plus de deux lettres, j'aime beaucoup .asms . .ast peut être confondu avec les arbres de syntaxe abstraite, et les autres sont juste plus bizarres que je ne le souhaiterais.

Il semble que .at est une extension très disponible, aucune langue que je puisse trouver, et presque aucun format de fichier, peut-être un, à partir de recherches rapides sur Google.

Voici une liste générée d'une tonne de possibilités pour vous aider à vous inspirer:

.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, je préfère .as , principalement pour des raisons esthétiques ( .js , .ts , _A_ssembly_S_cript). Je voudrais cependant avoir un serveur de langue pour en faire un bon usage avant de faire le changement.

.as me fait immédiatement penser à ActionScript, et il existe déjà des extensions VSCode.

Je préférerais .asms ou .ascr .

Jusqu'à présent, tout le monde a mentionné .a* pour une extension, mais est-ce que .ts* serait ouvert (comme .tsas ou .tsa ) car il dérive de TS?

Il y a aussi .was (l'étape avant .wasm ) mais cela peut déjà exister

Il y a aussi juste pour .ax ou quelque chose qui n'est pas un acronyme direct.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu. Merci pour vos contributions.

Prochaines étapes? Je ne veux juste pas que ça devienne périmé

Ou renommez simplement le script d'assemblage en script WASM légèrement plus descriptif et utilisez 'wass' pour compléter WASM, WAST, WASI, WAT, etc.

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu. Merci pour vos contributions.

Pas périmé. Comment une décision peut-elle être prise?

@lastmjs Lors de la dernière réunion, Saul Cabrera a mentionné qu'ils allaient commencer à travailler sur un serveur de langue: sourire:

Une fois que nous aurons cela, cela aidera grandement à résoudre ce problème, car nous aurons quelque chose qui reconnaît la syntaxe Assemblyscript, et nous permettra de commencer à écrire des plugins et des choses pour le langage dans d'autres outils et tels: smile:

De cette façon, nous n'aurons pas à dépendre des outils dactylographiés pour faire ce travail pour nous, et nous pouvons commencer à changer le nom de l'extension de fichier à partir de .ts : smile:

Je suis content que ce problème retienne l'attention. Mes 2 cents: .as est l'extension la plus intuitive d'AssemblyScript, comme dans un esprit similaire à .js , .ts . Je suis ravi d'entendre parler de travail sur un serveur lang aussi, cela ira un long chemin dans l'expérience de développement. Excellent travail à tous.

+1 pour .as .
Pas besoin de s'inquiéter du conflit avec les langues plus anciennes. Ils finiront par disparaître.
Excellent travail, BTW.

Je suis maintenant dans le camp d'extension. C'est probablement la décision la plus arbitraire à prendre, mais elle doit être prise.

@dcodeIO, nous avons une coloration syntaxique appropriée en travaillant avec une extension vscode, et la prise de décision à ce sujet devrait intervenir bientôt, si possible.

En attendant, je vais consacrer une grande majorité de mon temps à développer l'extension AssemblyScript tant attendue et convoitée en utilisant l'extension de fichier .asc . Grâce à la méthode compileString() , peu importe les extensions que nous utilisons, même si elles devraient être standardisées par le compilateur lui-même et être accompagnées d'une version de rupture du compilateur.

Peut-être qu'un RFC devrait être ouvert dans le repo AssemblyScript/meta .

CC @ torch2424 @willemneal et @MaxGraey

@jtenner Dope: smile: Oui, n'hésitez pas à ouvrir un RFC et à le lier ici! : sourire:: tada:

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu. Merci pour vos contributions.

Pas périmé! Comment va cette décision?

Nous attendons toujours que je termine asconfig et je crois que l'indicateur --extension est livré avec 0.10. Est-ce vrai, @dcodeIO?

Oui, le drapeau a atterri avec 0.10.0. L'utilisation est --extension .as par exemple, en remplaçant essentiellement tout .ts par .as . Notez, cependant, qu'asc ne comprend actuellement qu'une seule extension à la fois, ce qui entraînera très probablement des problèmes avec les bibliothèques externes en utilisant une autre. Plutôt une fonctionnalité expérimentale pour essayer des choses.

@dcodeIO Oh wow! Je n'avais aucune idée de ce qui avait atterri! Excellent travail là-dessus! : sourire:: +1:

Pour un projet simple dans un fichier fonctionne, merci! Et la syntaxe est maintenant mise en évidence.
Mais avec des choses comme rollup-plugin-assemblyscript ne l'est pas.

Edit: J'ai compris comment réparer ce plugin dont la version est obsolète. RP: https://github.com/surma/rollup-plugin-assemblyscript/pull/3