Assemblyscript: Рассмотрите расширение файла, кроме .ts

Это было бы полезно и для языкового сервера в vscode!

Это то, что мы могли бы рассмотреть в будущем, но в текущем состоянии, то есть без нашего собственного языкового сервера, повторное использование расширения .ts кажется лучшим, что мы можем сделать, чтобы обеспечить хороший опыт разработки.

Однако есть пара индикаторов, которые можно использовать для определения кода AS, например

• Если есть tsconfig.json расширяющий path/to/std/assembly.json , это каталог AS
• Если package.json имеет ascMain , это указывает на файл входа AS внутри каталога с другим кодом AS
• Точно так же, если package.json имеет сценарий asbuild , его нижние индексы указывают на файл входа AS
• Код AS обычно находится в assembly/ если не настроен иначе

Это то, что мы могли бы рассмотреть в будущем, но в текущем состоянии, то есть без нашего собственного языкового сервера, повторное использование расширения .ts кажется лучшим, что мы можем сделать, чтобы обеспечить хороший опыт разработки.

Я понимаю. Хотя разве не так просто указать VS Code обрабатывать файлы .as как файлы TypeScript? Я верю, что это так. Похоже, это был бы гораздо более простой способ получить преимущества статического анализа TypeScript в VS Code или аналогичных редакторах, и при этом получить преимущества отдельного расширения.

В прошлый раз я проверил, что tsc жестко запрограммировал поддерживаемые расширения файлов, и единственный способ изменить это - сохранить вилку. Это было примерно во время прототипа asc, но не знаю, изменилось ли оно.

Я думаю, это зависит от того, что вы имеете в виду под supported file extensions . TypeScript будет компилировать пути импорта с любым расширением файла. Проверка типов - единственное, что имеет проблемы с расширениями, и я считаю, что это не так уж сложно исправить с помощью простого расширения VS Code. На самом деле, я считаю, что Deno уже сделал это для расширений .ts : https://marketplace.visualstudio.com/items?itemName=justjavac.vscode-deno

Кроме того, у меня сейчас открыт VS Code, и я проинструктировал его обрабатывать файлы .as как TypeScript.

Я только что интегрировал здесь AssemblyScript: https://github.com/lastmjs/zwitterion

Оно работает! Но, как я уже сказал, это зависит от того, имеет ли AssemblyScript собственное расширение файла. На данный момент я выбрал .as . И я еще немного поэкспериментировал с VS Code, я могу проинструктировать его использовать .as как индикатор того, что это файл TypeScript, и он сохранит эту конфигурацию. Единственная серьезная проблема, которую я вижу, - это указание статическому анализатору TypeScript разрешить расширение .as, но, как и расширение Deno, на которое я ссылался выше, я не думаю, что это должно быть слишком сложно.

Есть ли здесь другие проблемы?

Кажется, проблема с ActionScript нарушает условия сделки для .as . Может, .asc ?

Лично мне не нравится идея о том, что расширение совпадает с компилятором. Хотелось бы, чтобы мы могли как-то включить Wasm, но мы не можем использовать .asm и это единственное, что я могу придумать.

Также @dcodeIO , RocketScript будет .rs ... Однако, если бы мы изменили имя сейчас, самое время. Моя единственная претензия к нынешнему названию заключается в том, что в нем слишком много слогов. Сохраняя космическую тему, мы могли бы сделать Ad Astra или Arugula (что в Великобритании называется ракетой).

.rs зарезервировано Rust =)

Просто хотел поднять, что эта проблема существует и для моего контекста: https://github.com/AssemblyScript/assemblyscript/issues/719

Кроме того, я думаю, что Github Languages будет хорошим справочником. Похоже, ActionScript уже конфликтует с AngelScript, поэтому, возможно, наш лучший вариант для продвижения вперед - открыть проблему с Github и посмотреть, можно ли добавить AssemblyScript в список как .as , поскольку это кажется популярным. вариант?

Например, мы спрашиваем, может ли AssemblyScript быть таким: .as и .assemblyscript ? 🤔

также, cc @jayphelps, так как у них было действительно хорошее понимание здесь 😄

Вот небольшое репо, показывающее, что GitHub сделает из .as . Также может быть разветвлен, чтобы увидеть, что нужно сделать, чтобы все работало как на стороне TS, так и на стороне AS:

https://github.com/dcodeIO/asext

И да, RocketScript / .rs самом деле я пытался подшутить :)

Кроме того, вот документы для добавления нового языка в детектор языка Github: https://github.com/github/linguist/blob/master/CONTRIBUTING.md#adding -a-language 😄

Однако было проведено некоторое исследование, и @dcodeIO был прав, похоже, что Typescript не поддерживает никаких расширений, кроме тех, которые они явно поддерживают: https://github.com/microsoft/TypeScript/issues/10939

Я начинаю соглашаться с тем, что, может быть, .as.ts имеет здесь наибольший смысл? 🤔

@ torch2424 .as.ts не поддерживается TypeScript при импорте. Как я уже упоминал несколько комментариев назад, это зависит от того, что вы подразумеваете под поддержкой. Кажется, единственная поддержка, в которой нуждается AssemblyScript, - это поддержка статического анализа в таких редакторах, как Visual Studio Code или Atom. Это верно? См. Решение Deno для разрешения расширений .ts при импорте TypeScript: https://github.com/justjavac/vscode-deno/blob/master/README.md Я не думаю, что было бы слишком сложно разветвить и расширить плагин до разрешить другое расширение, создав плагин AssemblyScript для VS Code.

Какая именно поддержка требуется от TypeScript? Компилятор уже может обрабатывать любое расширение, проверка типов - единственное, что имеет проблемы с расширениями, которые, как мне кажется, легко исправить с помощью плагинов.

Похоже, что фактическая логика исправления ошибок расширения .ts находится здесь: https://github.com/justjavac/typescript-deno-plugin

AssemblyScript в любом случае понадобится собственный языковой сервер, верно? Похоже, плагин для редакторов может быть естественным способом исправить эти проблемы с расширением с помощью средства проверки типов TypeScript. Я не думаю, что нам нужно ограничиваться чем-то, что заканчивается на .ts

@ torch2424 .as.ts также не поддерживается TypeScript при импорте. Как я уже упоминал несколько комментариев назад, это зависит от того, что вы подразумеваете под поддержкой.

Ой, плохо! Я пропустил мои извинения!

Какая именно поддержка требуется от TypeScript? Компилятор уже может обрабатывать любое расширение, проверка типов - единственное, что имеет проблемы с расширениями, которые, как мне кажется, легко исправить с помощью плагинов.

Ой, может я тогда ошибался, я не пробовал, но обнаружил ту открытую проблему, в которой люди не могут использовать другие расширения 😂

AssemblyScript в любом случае понадобится собственный языковой сервер, верно? Похоже, плагин для редакторов может быть естественным способом исправить эти проблемы с расширением с помощью средства проверки типов TypeScript. Я не думаю, что нам нужно ограничиваться чем-то, что заканчивается на .ts

Да, я думаю, что «правильно, @jtenner упомянул об этом, и я думаю, что у них было бы больше информации по этому

Но, если мы можем сделать что- то в tsconfig, например, использовать собственное расширение для файлов машинописного текста , я думаю, было бы хорошо, если бы мы выбрали .as 😄

Думаю, пора открыть новый вопрос с командой TypeScript и спросить их, есть ли способ вместо этого подключиться к их языковому серверу? Конечно, должен быть лучший способ сделать это с помощью расширения .ts .

Вот небольшое репо, показывающее, что GitHub сделает из .as . Также может быть разветвлен, чтобы увидеть, что нужно сделать, чтобы все работало как на стороне TS, так и на стороне AS:

https://github.com/dcodeIO/asext

И да, RocketScript / .rs самом деле я пытался подшутить :)

Это AngelScript согласно Github: D

@dcodeIO , кстати, я не могу скомпилировать ваше репо.

Я компилирую этот AngelScript как-то так: D

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

.as - это хорошо, но вы говорите ... это противоречит ActionScript? Чувак, я использовал его много лет назад. Макромедиа мертва. Adobe Flash мертв, Flex мертв. Так что ActionScript тоже мертв. +1 за .as name. Есть голосование?

Кстати, крутое движение: js -> ts -> as

(Кроме того, было бы здорово, если бы AssemblyScript был надмножеством TypeScript, а не подмножеством)

Я согласен, .as все вокруг кажется лучшим, наиболее естественным и наиболее удобным выбором, за исключением конфликтов с другими языками. Я думаю, если это вообще возможно, если мы каким-то образом сможем заставить .as работать, тогда мы должны это сделать. Если другие языки мертвы или умирают, кажется разумным, что AssemblyScript должен попытаться сделать расширение отличным.

Переход на .as - действительно сложный процесс. Мы можем получить одобрение от GitHub (github / лингвист). Для этого язык должен быть достаточно зрелым. Также необходимо обновить широкий спектр редакторов и IDE.

@MaxGraey да, это правда. И везде в документации, примерах и т. Д. - везде нужно упоминать .as , - это, наверное, самая сложная часть.

Исправить подсветку в VSCode очень просто:

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

Хотя в идеале не следует управлять индивидуальными настройками каждого человека. Вероятно, это должен быть отдельный плагин, который будет автоматически предлагаться при первом открытии файла .as - гораздо удобнее, чем ручное управление конфигурацией. Или даже сделать PR в существующем плагине TS, чтобы подсчитать .as как машинописный текст ... Эквивалентны ли они синтаксически?

Здравствуйте!

Мы обсуждали эту проблему в https://github.com/AssemblyScript/meta/issues/19.

Основное решение, которое мы получили от этого, было:

Нам нужен список вещей, которые язык должен сделать, чтобы получить поддержку в большинстве основных IDE, а также в Github.

Поскольку AssemblyScript заимствовал расширение .ts , это означает, что нам нужно построить всю инфраструктуру для поддержки собственного имени расширения. Например, как попасть в репозиторий лингвистов на Github, как получить поддержку кода Visual Studio.

Как только мы получим это, мы сможем разбить его на проблемы. А затем мы можем выбрать окончательное название, под которым люди могут заниматься этими проблемами, и начать реализацию.

На еженедельной встрече предлагались и другие имена (мое новое любимое - .asms (Asm Script)), и да! 😄

PS В то же время, если мы уверены, что хотим изменить имя расширения, лучше сделать это сейчас, чем позже. Причина в том, что чем больше людей будут использовать AS, тем сложнее будет всем изменить имена расширений.

Как насчет .at (первая и последняя буква AssemblyScript)?

.as (конфликтует с двумя другими языками на GitHub)
.at
.ast
.asc (конфликтует с 3 другими языками на GitHub)
.asmt
.asmc
.asms
.asmst
.asmscript
.assemblyscript

.as - мой выбор номер один без учета конфликтующих языков, затем .at и .asms . Мне нравится идея двухбуквенного расширения, потому что она соответствует наследию самых популярных языков на основе JS, .js и .ts . Если нам нужно использовать более двух букв, мне очень нравится .asms . .ast можно спутать с абстрактными синтаксическими деревьями, а другие просто более странные, чем мне хотелось бы.

Похоже, что .at - очень доступное расширение, никаких языков, которые я могу найти, и почти никаких форматов файлов, может быть, одного, из некоторых быстрых поисков в Google.

Вот сгенерированный список из множества возможностей для вдохновения:

.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, я предпочитаю .as , в основном из эстетических соображений ( .js , .ts , _A_ssembly_S_cript). Тем не менее, хотелось бы иметь языковой сервер, чтобы правильно его использовать, прежде чем переключаться.

.as сразу наводит на мысль об ActionScript, и для него уже есть расширения VSCode.

Я бы предпочел .asms или .ascr .

Все до сих пор упоминали .a* для расширения, но будет ли .ts* открытым (например, .tsas или .tsa ), поскольку он ответвляется от TS?

Также есть .was (шаг перед .wasm ), но он может уже существовать

Также есть просто .ax или что-то, что не является прямым акронимом.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Спасибо за ваш вклад.

Следующие шаги? Просто не хочу, чтобы это стало устаревшим

Или просто переименуйте Assembly Script в более информативный WASM Script и используйте wass для дополнения WASM, WAST, WASI, WAT и т. Д.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Спасибо за ваш вклад.

Не устаревший. Как можно принять решение?

@lastmjs Во время последней встречи Саул Кабрера упомянул, что они собираются начать работу над языковым сервером: smile:

Как только мы это сделаем, это очень поможет решить эту проблему, поскольку у нас будет что-то, что распознает синтаксис Assemblyscript и позволит нам начать писать плагины и вещи для языка в других инструментах и ​​тому подобном: smile:

Таким образом, нам не придется полагаться на инструменты машинописного текста, чтобы сделать эту работу за нас, и мы можем начать изменять имя расширения файла с .ts : smile:

Я рад, что этому вопросу уделяется внимание. Мои 2 цента: .as - наиболее интуитивное расширение AssemblyScript, аналогичное .js , .ts . Я рад услышать о работе над lang-сервером, это будет иметь большое значение в опыте разработчиков. Отличная работа всем.

+1 за .as .
Не нужно беспокоиться о конфликте со старыми языками. Со временем они исчезнут.
Отличная работа, кстати.

Я сейчас нахожусь в дополнительном лагере. Это, вероятно, наиболее произвольное решение, но оно должно быть принято.

@dcodeIO у нас есть правильная подсветка синтаксиса, работающая с расширением vscode, и решение об этом должно произойти в ближайшее время, если возможно.

А пока я собираюсь потратить большую часть своего времени на разработку долгожданного и желанного расширения AssemblyScript с использованием расширения файла .asc . Благодаря методу compileString() не имеет значения, какие расширения мы используем, даже если он должен быть стандартизирован самим компилятором и поставляться с последней версией компилятора.

Возможно, следует открыть RFC в репозитории AssemblyScript/meta .

CC @ torch2424 @willemneal и @MaxGraey

@jtenner Dope: smile: Да, не стесняйтесь открывать RFC и ссылаться на него здесь! : smile:: tada:

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Спасибо за ваш вклад.

Не несвежий! Как продвигается это решение?

Мы все еще ждем, пока я закончу asconfig, и я считаю, что флаг --extension поставляется с 0.10.0. Правильно, @dcodeIO?

Да, флаг приземлился с 0.10.0. Использование, например, --extension .as , по сути заменяет любые .ts на .as . Обратите внимание, однако, что asc в настоящее время понимает только одно расширение за раз, что, скорее всего, приведет к проблемам с внешними библиотеками, использующими другое. Скорее экспериментальная функция, чтобы попробовать.

@dcodeIO Ого ! Я понятия не имел, что приземлился! Отличная работа над этим! : smile:: +1:

За простой проект в одном файле работает, спасибо! И синтаксис теперь выделен.
Но с такими вещами, как rollup-plugin-assemblyscript - нет.

Изменить: я понял, как исправить этот плагин с устаревшей версией. PR: https://github.com/surma/rollup-plugin-assemblyscript/pull/3