Assemblyscript: Considere una extensión de archivo que no sea .ts

¡Esto también sería útil para un servidor de idiomas en vscode!

Esto es algo que podríamos considerar en el futuro, pero en el estado actual, es decir, sin nuestro propio servidor de idioma, reutilizar la extensión .ts parece ser lo mejor que podemos hacer razonablemente para proporcionar una buena experiencia de desarrollo.

Sin embargo, hay un par de indicadores que las herramientas pueden usar para determinar qué es el código AS, como

• Si hay un tsconfig.json extendiendo path/to/std/assembly.json , ese es un directorio AS
• Si package.json tiene un ascMain , eso apunta a un archivo de entrada AS dentro de un directorio con otro código AS
• De manera similar, si package.json tiene un script asbuild , sus subíndices apuntan a un archivo de entrada AS
• El código AS generalmente vive en assembly/ si no se configura de otra manera

Esto es algo que podríamos considerar en el futuro, pero en el estado actual, es decir, sin nuestro propio servidor de idioma, reutilizar la extensión .ts parece ser lo mejor que podemos hacer razonablemente para proporcionar una buena experiencia de desarrollo.

Entiendo. Sin embargo, ¿no es sencillo instruir a VS Code para que trate los archivos .as como archivos TypeScript? Yo creo que lo es. Parece que esa sería una forma mucho más sencilla de obtener los beneficios del análisis estático de TypeScript en VS Code o editores similares, y aún así obtener los beneficios de tener una extensión separada.

La última vez que verifiqué tsc codificó las extensiones de archivo compatibles y la única forma de cambiarlo fue mantener una bifurcación. Eso fue en la época del prototipo de asc, sin embargo, no sé si cambió.

Creo que depende aquí de lo que quieras decir con supported file extensions . TypeScript compilará rutas de importación con cualquier extensión de archivo. El comprobador de tipos es lo único que tiene problemas con las extensiones, y creo que no es demasiado difícil de solucionar con una simple extensión de VS Code. De hecho, creo que Deno ya ha hecho esto para las extensiones .ts : https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

Además, tengo VS Code abierto en este momento, y le indiqué que tratara los archivos .as como TypeScript.

Acabo de integrar AssemblyScript aquí: https://github.com/lastmjs/zwitterion

¡Funciona! Pero, como dije, depende de que AssemblyScript tenga su propia extensión de archivo. Por ahora, elegí ir con .as . Y he experimentado con VS Code un poco más, puedo indicarle que use .as como indicador de ser un archivo TypeScript, y guardará esa configuración. El único problema importante que veo es indicarle al analizador estático TypeScript que permita la extensión .as, pero al igual que la extensión Deno a la que me vinculé anteriormente, no creo que esto deba ser demasiado difícil.

¿Hay otros problemas aquí?

Parece que el problema de ActionScript es un factor decisivo para .as . ¿Quizás .asc ?

Personalmente, no me gusta la idea de que la extensión sea la misma que el compilador. Ojalá pudiéramos incorporar Wasm de alguna manera, pero no podemos usar .asm y es el único en el que puedo pensar.

También @dcodeIO , RocketScript sería .rs ... Sin embargo, si tuviéramos que cambiar el nombre ahora sería el momento. Mi única queja con el nombre actual es que tiene demasiadas sílabas. Siguiendo con el tema del espacio, podríamos hacer Ad Astra , o Arugula (que se llama cohete en el Reino Unido).

.rs reservado por Rust =)

Solo quería mencionar que también existe este problema para mi contexto: https://github.com/AssemblyScript/assemblyscript/issues/719

Además, creo que los idiomas Github serían una buena referencia. Parece que ActionScript ya está en conflicto con AngelScript, por lo tanto, tal vez nuestra mejor apuesta aquí para seguir adelante es abrir un problema con Github y ver si AssemblyScript podría agregarse a la lista como .as , ya que parece ser el popular ¿opción?

Como en, preguntamos si AssemblyScript podría ser: .as y .assemblyscript ? 🤔

también, cc @jayphelps, ya que tuvieron una idea muy buena aquí 😄

Aquí hay un pequeño repositorio que muestra lo que GitHub haría con .as . También se puede bifurcar para ver qué se debe hacer para que todo funcione tanto en el lado TS como en el AS:

https://github.com/dcodeIO/asext

Y sí, RocketScript / .rs realidad era yo tratando de ser gracioso :)

Además, aquí están los documentos para agregar un nuevo idioma al detector de idioma Github: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding -a-language 😄

Sin embargo, investigué un poco y @dcodeIO estaba en lo correcto, parece que Typecript no admite ninguna extensión que no sean las que admiten explícitamente: https://github.com/microsoft/TypeScript/issues/10939

Estoy empezando a estar de acuerdo con que quizás .as.ts tenga más sentido aquí. 🤔

@ torch2424 .as.ts tampoco es compatible con TypeScript en las importaciones. Como mencioné hace algunos comentarios, depende de lo que quieras decir con soporte. Parece que el único soporte que necesita AssemblyScript es el soporte de análisis estático en editores como Visual Studio Code o Atom. ¿Es esto correcto? Vea la solución de Deno para permitir extensiones .ts en importaciones de TypeScript: https://github.com/justjavac/vscode-deno/blob/master/README.md No creo que sea demasiado difícil bifurcar y extender el complemento a permitir otra extensión, creando un complemento de AssemblyScript para VS Code.

¿Exactamente qué tipo de soporte se necesita de TypeScript? El compilador ya puede manejar cualquier extensión, el comprobador de tipos es lo único que tiene problemas con las extensiones, que imagino que se soluciona fácilmente con complementos

Parece que la lógica real para corregir los errores de extensión .ts está aquí: https://github.com/justjavac/typescript-deno-plugin

AssemblyScript eventualmente necesitará su propio servidor de lenguaje de todos modos, ¿correcto? Parece que un complemento para editores podría ser una forma natural de solucionar estos problemas de extensión con el verificador de tipo TypeScript. No creo que debamos limitarnos a algo que termine en .ts

TypeScript tampoco

¡Oh mi error! ¡Me perdí mis disculpas!

¿Exactamente qué tipo de soporte se necesita de TypeScript? El compilador ya puede manejar cualquier extensión, el comprobador de tipos es lo único que tiene problemas con las extensiones, que imagino que se soluciona fácilmente con complementos

Vaya, tal vez me equivoqué entonces, no lo había probado, pero encontré ese problema abierto en el que la gente no podía usar otras extensiones 😂

AssemblyScript eventualmente necesitará su propio servidor de lenguaje de todos modos, ¿correcto? Parece que un complemento para editores podría ser una forma natural de solucionar estos problemas de extensión con el verificador de tipo TypeScript. No creo que debamos limitarnos a algo que termine en .ts

Sí, creo que 'correcto, @jtenner mencionó esto, y creo que tendrían más antecedentes al respecto.

Pero, si podemos hacer algo en tsconfig, de modo que pueda usar una extensión personalizada para los archivos mecanografiados , creo que sería bueno si fuéramos con .as 😄

Creo que es hora de que abramos un nuevo problema con el equipo de TypeScript y les preguntemos si hay alguna forma de conectarse a su servidor de idiomas. Seguramente debe haber una mejor manera de hacer esto con la extensión .ts .

Aquí hay un pequeño repositorio que muestra lo que GitHub haría con .as . También se puede bifurcar para ver qué se debe hacer para que todo funcione tanto en el lado TS como en el AS:

https://github.com/dcodeIO/asext

Y sí, RocketScript / .rs realidad era yo tratando de ser gracioso :)

Este es un AngelScript según Github: D

@dcodeIO, por cierto, no puedo compilar su repositorio.

Estoy compilando este AngelScript de alguna manera así: D

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

.as es bueno pero dice ... ¿está en conflicto con ActionScript? Hombre, lo he usado hace eones. Macromedia está muerta. Adobe Flash está muerto, Flex está muerto. Así que ActionScript también está muerto. +1 por .as nombre. ¿Hay votación?

Por cierto, es un movimiento genial: js -> ts -> as

(Además, sería bueno que AssemblyScript fuera un superconjunto de TypeScript, no un subconjunto)

Estoy de acuerdo, .as parece la mejor opción, la más natural y la más cómoda, excepto por conflictos con otros idiomas. Creo que si es posible, si de alguna manera podemos hacer que .as funcione, deberíamos hacerlo. Si los otros lenguajes están muertos o muriendo, parece razonable que AssemblyScript tenga la oportunidad de hacer que la extensión sea excelente.

Cambiar a .as es un proceso realmente difícil. Podríamos obtener la aprobación de GitHub (github / linguist). El lenguaje debería ser bastante maduro para eso. También es necesario actualizar una amplia gama de editores e IDE.

@MaxGraey sí, eso es cierto. Y en todas partes en los documentos, ejemplos, etc., en todas partes se debe mencionar .as , esa es probablemente la parte más difícil.

Es muy fácil arreglar el resaltado en VSCode:

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

Aunque, idealmente, no debería ser administrado por la configuración de cada persona. Probablemente debería ser un complemento separado, que se sugerirá automáticamente una vez que abra el archivo .as por primera vez, mucho más fácil de usar que la administración de configuración manual. O incluso convertir PR en el plugin TS existente para contar .as como mecanografiado ... ¿Son sintácticamente equivalentes?

¡Hola!

Tuvimos una discusión sobre este problema en https://github.com/AssemblyScript/meta/issues/19

El principal elemento procesable que obtuvimos fue:

Necesitamos una lista de cosas que debería hacer el lenguaje para obtener soporte en la mayoría de los IDE principales, así como en Github.

Dado que AssemblyScript se ha aprovechado de la extensión .ts , esto significa que debemos compilar toda la infraestructura para admitir nuestro propio nombre de extensión. Por ejemplo, ¿cómo accedemos al repositorio de lingüistas de Github? ¿Cómo conseguimos Visual Studio Code Support?

Una vez que tengamos eso, podemos dividirlo en problemas. Y luego podemos decidir un nombre final, en el que la gente pueda abordar esos temas y comenzar la implementación.

Se propusieron otros nombres en la reunión semanal (Mi nuevo favorito es .asms (Asm Script)), ¡y sí! 😄

PD: Al mismo tiempo, si estamos seguros de que queremos cambiar el nombre de la extensión, es mucho mejor hacerlo ahora que más tarde. La razón es que a medida que más personas adopten AS, más difícil será para todos cambiar los nombres de las extensiones.

¿Qué tal .at (primera y última letra de AssemblyScript)?

.as (entra en conflicto con otros 2 idiomas en GitHub)
.at
.ast
.asc (entra en conflicto con otros 3 idiomas en GitHub)
.asmt
.asmc
.asms
.asmst
.asmscript
.assemblyscript

.as es mi opción número uno sin tener en cuenta los idiomas en conflicto, luego .at y .asms . Me gusta la idea de una extensión de dos letras porque va de la mano con la herencia de los lenguajes basados ​​en JS más populares, .js y .ts . Si tenemos que ir más de dos letras, me gusta mucho .asms . .ast podría confundirse con árboles de sintaxis abstracta, y los otros son más raros de lo que me gustaría.

Parece que .at es una extensión muy disponible, no hay idiomas que pueda encontrar y casi no hay formatos de archivo, tal vez uno, de algunas búsquedas rápidas de Google.

Aquí hay una lista generada de un montón de posibilidades para ayudar en la inspiración:

.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, estoy favoreciendo .as , principalmente por razones estéticas ( .js , .ts , _A_ssembly_S_cript). Sin embargo, me gustaría tener un servidor de idiomas para hacer un uso adecuado de él antes de hacer el cambio.

.as inmediatamente me hace pensar en ActionScript, y ya existen extensiones de VSCode para él.

Yo preferiría .asms o .ascr .

Hasta ahora, todos han mencionado .a* para una extensión, pero ¿ .ts* estaría abierto (como .tsas o .tsa ) ya que se está ramificando desde TS?

También hay .was (el paso antes de .wasm ) pero es posible que ya exista

También va por .ax o algo que no sea un acrónimo directo.

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

¿Próximos pasos? Simplemente no quiero que esto se vuelva rancio

O simplemente cambie el nombre de Assembly Script por el WASM Script un poco más descriptivo y use 'wass' para complementar WASM, WAST, WASI, WAT, etc.

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

No rancio. ¿Cómo se puede tomar una decisión?

@lastmjs En la última reunión, Saúl Cabrera mencionó que iban a comenzar a trabajar en un servidor de idiomas: smile:

Una vez que tengamos eso, eso ayudará enormemente a impulsar este problema, ya que tendremos algo que reconoce la sintaxis de Assemblyscript y nos permitirá comenzar a escribir complementos y cosas para el lenguaje en otras herramientas y como: smile:

De esa manera, no tendremos que depender de las herramientas mecanografiadas para hacer este trabajo por nosotros, y podemos comenzar a cambiar el nombre de la extensión del archivo de .ts : smile:

Me alegro de que este problema esté recibiendo atención. Mis 2 centavos: .as es la extensión más intuitiva de AssemblyScript, con un espíritu similar a .js , .ts . También estoy emocionado de escuchar sobre el trabajo en un servidor lang, esto será de gran ayuda en la experiencia de desarrollo. Buen trabajo todo.

+1 por .as .
No hay necesidad de preocuparse por el conflicto con los idiomas más antiguos. Eventualmente se desvanecerán.
Buen trabajo, por cierto.

Estoy en el campamento de extensión ahora. Esta es probablemente la decisión más arbitraria que se debe tomar, pero debería tomarse.

@dcodeIO tenemos un resaltado de sintaxis adecuado trabajando con una extensión de vscode, y tomar una decisión al respecto debería suceder pronto, si es posible.

Mientras tanto, voy a dedicar la mayor parte de mi tiempo a desarrollar la tan esperada y codiciada extensión de AssemblyScript usando la extensión de archivo .asc . Gracias al método compileString() , no importará qué extensiones usemos, aunque debería estar estandarizado por el propio compilador y venir con una versión definitiva del compilador.

Quizás debería abrirse un RFC en el repositorio AssemblyScript/meta .

CC @ torch2424 @willemneal y @MaxGraey

@jtenner Dope: smile: ¡Sí, siéntete libre de abrir un RFC y vincularlo aquí! : sonrisa:: tada:

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

¡No rancio! ¿Cómo va esa decisión?

Todavía estamos esperando que termine asconfig y creo que el indicador --extension se envió con 0.10. ¿Es así, @dcodeIO?

Sí, la bandera aterrizó con 0.10.0. El uso es --extension .as por ejemplo, esencialmente reemplazando cualquier .ts con .as . Sin embargo, tenga en cuenta que asc comprende exactamente una extensión a la vez en la actualidad, lo que muy probablemente ocasione problemas con las bibliotecas externas que usan una diferente. Más bien una función experimental para probar cosas.

@dcodeIO ¡Oh, guau! ¡No tenía ni idea de que había aterrizado! ¡Buen trabajo en eso! : sonrisa:: +1:

Para trabajos simples en un archivo, ¡gracias! Y la sintaxis está resaltada ahora.
Pero con cosas como rollup-plugin-assemblyscript no lo es.

Editar: Descubrí cómo arreglar este complemento, tiene una versión obsoleta. PR: https://github.com/surma/rollup-plugin-assemblyscript/pull/3