Assemblyscript: Considere uma extensão de arquivo diferente de .ts

Isso também seria útil para um servidor de linguagem em vscode!

Isso é algo que podemos considerar no futuro, mas no estado atual, sem nosso próprio servidor de idioma, reutilizar a extensão .ts parece ser o melhor que podemos fazer para fornecer uma boa experiência de desenvolvimento.

Existem alguns indicadores, porém, que as ferramentas podem usar para determinar o que é o código AS, como

• Se houver um tsconfig.json estendendo path/to/std/assembly.json , esse é um diretório AS
• Se package.json tem um ascMain , isso está apontando para um arquivo de entrada AS dentro de um diretório com outro código AS
• Da mesma forma, se package.json tem um script asbuild , seus subscritos apontam para um arquivo de entrada AS
• O código AS geralmente reside em assembly/ se não for configurado de outra forma

Isso é algo que podemos considerar no futuro, mas no estado atual, sem nosso próprio servidor de idioma, reutilizar a extensão .ts parece ser o melhor que podemos fazer para fornecer uma boa experiência de desenvolvimento.

Compreendo. Porém, não é simples instruir o VS Code a tratar .as arquivos como arquivos TypeScript? Eu acredito que sim. Parece que essa seria uma maneira muito mais simples de obter os benefícios da análise estática do TypeScript no VS Code ou editores semelhantes e ainda obter os benefícios de ter uma extensão separada.

A última vez que verifiquei o tsc codificou as extensões de arquivo com suporte e a única maneira de alterá-lo era manter um fork. Isso foi na época do protótipo asc, porém, não sei se mudou.

Acho que depende aqui do que você entende por supported file extensions . TypeScript irá compilar caminhos de importação com qualquer extensão de arquivo. O verificador de tipo é a única coisa que tem problemas com extensões, e acredito que não seja muito difícil de consertar com uma simples extensão do VS Code. Na verdade, acredito que Deno já fez isso para .ts extensions: https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

Além disso, estou com o VS Code aberto agora e o instruí a tratar .as arquivos como TypeScript.

Acabei de integrar o AssemblyScript aqui: https://github.com/lastmjs/zwitterion

Funciona! Mas, como eu disse, depende do AssemblyScript ter sua própria extensão de arquivo. Por enquanto, escolhi .as . E eu experimentei um pouco mais com o VS Code, posso instruí-lo a usar .as como um indicador de ser um arquivo TypeScript, e ele salvará essa configuração. O único grande problema que vejo é instruir o analisador estático TypeScript a permitir a extensão .as, mas, como aquela extensão Deno que vinculei acima, não acho que isso deva ser muito difícil.

Existem outros problemas aqui?

Parece que o problema do ActionScript é um obstáculo para .as . Talvez .asc ?

Pessoalmente, não gosto da ideia da extensão ser igual ao compilador. Eu gostaria que pudéssemos incorporar Wasm de alguma forma, mas não podemos usar .asm e é o único que consigo pensar.

Também @dcodeIO , RocketScript seria .rs ... No entanto, se mudássemos o nome agora seria a hora. Minha única reclamação com o nome atual é que ele contém muitas sílabas. Mantendo o tema espacial, poderíamos fazer Ad Astra , ou Arugula (que é chamado de foguete no Reino Unido).

.rs reservado por Rust =)

Só queria ressaltar que também existe esse problema para o meu contexto: https://github.com/AssemblyScript/assemblyscript/issues/719

Além disso, acho que as Línguas do .as , já que parece ser o popular opção?

Como em, perguntamos se o AssemblyScript poderia ser: .as e .assemblyscript ? 🤔

também, cc @jayphelps, pois eles tiveram uma visão muito boa aqui 😄

Aqui está um pequeno repositório que mostra o que o GitHub faria com .as . Também pode ser bifurcado para ver o que precisa ser feito para fazer tudo funcionar tanto no lado TS quanto no lado AS:

https://github.com/dcodeIO/asext

E sim, RocketScript / .rs na verdade eu estava tentando ser engraçado :)

Além disso, aqui estão os documentos para adicionar um novo idioma ao detector de idiomas do Github: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding -a-language 😄

No entanto, fiz algumas pesquisas e @dcodeIO estava correto. Parece que o Typescript não oferece suporte a nenhuma extensão além das explicitamente compatíveis: https://github.com/microsoft/TypeScript/issues/10939

Estou começando a concordar que talvez .as.ts faça mais sentido aqui? 🤔

@ torch2424 .as.ts também não é compatível com o TypeScript nas importações. Como mencionei há alguns comentários, depende do que você entende por suporte. Parece que o único suporte de que o AssemblyScript precisa é o suporte de análise estática em editores como Visual Studio Code ou Atom. Isso está correto? Veja a solução de Deno para permitir extensões .ts em importações TypeScript: https://github.com/justjavac/vscode-deno/blob/master/README.md Não imagino que seja muito difícil bifurcar e estender o plugin para permitir outra extensão, criando um plugin AssemblyScript para o código VS.

Exatamente que tipo de suporte é necessário do TypeScript? O compilador já pode lidar com qualquer extensão, o typechecker é a única coisa que tem problemas com extensões, que eu imagino que seja facilmente corrigido com plugins

Parece que a lógica real para corrigir os erros de extensão .ts está aqui: https://github.com/justjavac/typescript-deno-plugin

O AssemblyScript precisará de seu próprio servidor de linguagem eventualmente, correto? Parece que um plug-in para editores pode ser uma maneira natural de corrigir esses problemas de extensão com o verificador de tipo TypeScript. Não acho que precisamos nos limitar a algo que termina com .ts

@ torch2424 .as.ts também não é compatível com o TypeScript nas importações. Como mencionei há alguns comentários, depende do que você entende por suporte.

Oh culpa minha! Eu perdi isso minhas desculpas!

Exatamente que tipo de suporte é necessário do TypeScript? O compilador já pode lidar com qualquer extensão, o typechecker é a única coisa que tem problemas com extensões, que eu imagino que seja facilmente corrigido com plugins

Opa, talvez eu estivesse errado, não tinha tentado, mas encontrei aquele problema aberto em que as pessoas não podiam usar outras extensões 😂

O AssemblyScript precisará de seu próprio servidor de linguagem eventualmente, correto? Parece que um plug-in para editores pode ser uma maneira natural de corrigir esses problemas de extensão com o verificador de tipo TypeScript. Não acho que precisamos nos limitar a algo que termina com .ts

Sim, acho que correto, @jtenner mencionou isso, e acho que eles têm mais informações sobre isso.

Mas, se pudermos fazer ssalgo no tsconfig, de forma que ele possa usar uma extensão personalizada para arquivos typescript , acho que seria bom se usássemos .as 😄

Acho que é hora de abrirmos um novo problema com a equipe do TypeScript e perguntar se há uma maneira de se conectar ao servidor de linguagem? Certamente deve haver uma maneira melhor de fazer isso com a extensão .ts .

Aqui está um pequeno repositório que mostra o que o GitHub faria com .as . Também pode ser bifurcado para ver o que precisa ser feito para fazer tudo funcionar tanto no lado TS quanto no lado AS:

https://github.com/dcodeIO/asext

E sim, RocketScript / .rs na verdade eu estava tentando ser engraçado :)

Este é um AngelScript de acordo com Github: D

A propósito ,

Estou compilando este AngelScript de alguma forma assim: D

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

.as é bom, mas você diz ... está em conflito com o ActionScript? Cara, eu usei isso há muito tempo. A Macromedia está morta. Adobe Flash está morto, Flex está morto. Portanto, o ActionScript também está morto. 1 para .as name. Existe uma votação?

A propósito, é um movimento legal: js -> ts -> as

(Além disso, seria legal o AssemblyScript ser um superconjunto do TypeScript, não um subconjunto)

Eu concordo, .as parece ser a melhor escolha, mais natural e mais confortável, exceto para conflitos com outros idiomas. Eu acho que se possível, se nós pudermos de alguma forma fazer .as funcionar, então devemos. Se as outras linguagens estão mortas ou morrendo, parece razoável que o AssemblyScript tenha uma chance de tornar a extensão excelente.

Mudar para .as é um processo realmente difícil. Podemos obter a aprovação do GitHub (github / linguista). A linguagem deve ser bastante madura para isso. Também precisa atualizar uma ampla gama de editores e IDEs.

@MaxGraey sim, é verdade. E em todos os lugares nos documentos, exemplos, etc. - em todos os lugares devem ser mencionados .as , - essa é provavelmente a parte mais difícil.

É muito fácil corrigir o realce no VSCode:

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

Porém, idealmente, não deve ser gerenciado pelas configurações de cada pessoa. Provavelmente deve ser um plugin separado, que será sugerido automaticamente assim que você abrir o arquivo .as pela primeira vez, - muito mais amigável do que o gerenciamento de configuração manual. Ou mesmo para transformar PR em um plugin TS existente para contar .as como texto digitado ... Eles são sintaticamente equivalentes?

Olá!

Discutimos esse problema em https://github.com/AssemblyScript/meta/issues/19

O principal item acionável que obtivemos foi:

Precisamos de uma lista das coisas que a linguagem precisa fazer para obter suporte na maioria dos IDEs principais, bem como no Github.

Já que o AssemblyScript está pegando carona na extensão .ts , isso significa que precisamos construir toda a infra para suportar nosso próprio nome de extensão. Por exemplo, como entramos no repositório lingüista do Github, como obtemos Suporte a código do Visual Studio.

Assim que tivermos isso, podemos dividir em questões. E então podemos decidir sobre um nome final, no qual as pessoas podem assumir essas questões e iniciar a implementação.

Outros nomes foram propostos na reunião semanal (meu novo favorito é .asms (Asm Script)), e sim! 😄

PS Ao mesmo tempo, se tivermos certeza de que queremos alterar o nome da extensão, é muito melhor fazer isso agora do que depois. A razão é que quanto mais pessoas adotam AS, mais difícil será para todos mudarem os nomes das extensões.

Que tal .at (primeira e última letra do AssemblyScript)?

.as (conflita com 2 outros idiomas no GitHub)
.at
.ast
.asc (conflita com 3 outros idiomas no GitHub)
.asmt
.asmc
.asms
.asmst
.asmscript
.assemblyscript

.as é minha escolha número um sem levar em consideração idiomas conflitantes, então .at e .asms . Eu gosto da ideia de uma extensão de duas letras porque vai junto com a herança das linguagens baseadas em JS mais populares, .js e .ts . Se tivermos que ir mais de duas letras, eu realmente gosto de .asms . .ast pode ser confundido com Árvores de sintaxe abstrata, e as outras são mais estranhas do que eu gostaria.

Parece que .at é uma extensão muito disponível, nenhum idioma que eu possa encontrar e quase nenhum formato de arquivo, talvez um, de algumas pesquisas rápidas no Google.

Aqui está uma lista gerada de uma tonelada de possibilidades para ajudar na inspiração:

.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, estou favorecendo .as , principalmente por razões estéticas ( .js , .ts , _A_ssembly_S_cript). Gostaria de ter um servidor de idioma para fazer uso adequado antes de fazer a troca, no entanto.

.as imediatamente me faz pensar em ActionScript, e já existem extensões VSCode para ele.

Eu favoreceria .asms ou .ascr .

Todos até agora mencionaram .a* para uma extensão, mas .ts* estaria aberto (como .tsas ou .tsa ), visto que está se ramificando do TS?

Também há .was (a etapa anterior a .wasm ), mas pode já existir

Também há apenas .ax ou algo que não seja uma sigla direta.

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Próximos passos? Só não quero que isso fique velho

Ou apenas renomeie o Assembly Script para o WASM Script um pouco mais descritivo e use 'wass' para complementar WASM, WAST, WASI, WAT, etc.

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Não velho. Como uma decisão pode ser tomada?

@lastmjs Na última reunião, Saul Cabrera mencionou que eles iriam começar a trabalhar em um servidor de linguagem: smile:

Assim que tivermos isso, isso ajudará muito a impulsionar esse problema, uma vez que teremos algo que reconhece a sintaxe do Assemblyscript e nos permite começar a escrever plug-ins e coisas para a linguagem em outras ferramentas e tais: smile:

Dessa forma, não teremos que depender das ferramentas de digitação para fazer este trabalho para nós, e podemos começar a mudar o nome da extensão do arquivo de .ts : smile:

Estou feliz que este problema esteja recebendo alguma atenção. Meus 2 centavos: .as é a extensão mais intuitiva do AssemblyScript, semelhante a .js , .ts . Também estou animado para saber sobre o trabalho em um servidor lang, isso ajudará muito na experiência de desenvolvimento. Ótimo trabalho.

+1 para .as .
Não precisa se preocupar com o conflito com idiomas mais antigos. Eles irão desaparecer eventualmente.
Bom trabalho, BTW.

Estou no campo de extensão agora. Esta é provavelmente a decisão mais arbitrária a se tomar, mas deve ser tomada.

@dcodeIO , temos o realce de sintaxe adequado para trabalhar com uma extensão vscode, e tomar uma decisão sobre isso deve acontecer logo, se possível.

Enquanto isso, vou dedicar a maior parte do meu tempo para desenvolver a tão esperada e cobiçada extensão do AssemblyScript usando a extensão de arquivo .asc . Graças ao método compileString() , não importa quais extensões usamos, mesmo que deva ser padronizado pelo próprio compilador e vir com uma versão mais recente do compilador.

Talvez uma RFC deva ser aberta no repo AssemblyScript/meta .

CC @ torch2424 @willemneal e @MaxGraey

@jtenner Dope: smile: Sim,

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Não velho! Como está indo essa decisão?

Ainda estamos esperando que eu termine o asconfig e acredito que o sinalizador --extension foi enviado com 0,10. Isso está certo, @dcodeIO?

Sim, a bandeira caiu com 0.10.0. O uso é --extension .as por exemplo, essencialmente substituindo qualquer .ts por .as . Observe, entretanto, que asc entende exatamente uma extensão por vez atualmente, muito provavelmente levando a problemas com bibliotecas externas usando uma extensão diferente. Em vez disso, um recurso experimental para experimentar.

@dcodeIO Oh, uau! Eu não tinha ideia de que tinha pousado! Ótimo trabalho nisso! : smile:: +1:

Para trabalhos de projeto simples em um arquivo, obrigado! E a sintaxe está destacada agora.
Mas com coisas como rollup-plugin-assemblyscript não é.

Edit: Eu descobri como consertar este plugin, ele tem uma versão desatualizada. PR: https://github.com/surma/rollup-plugin-assemblyscript/pull/3