ОБНОВЛЕНИЕ ОБНОВЛЕНИЕ: Deno (на 0.39.0) сильно изменился, хотя некоторая информация здесь все еще актуальна, некоторая не устарела. Я бы просто рекомендовал использовать Deno VSCode plugin от axetroy (который построен на плагине от justjavac). Это полуофициально, и изменения в Deno, влияющие на плагин, быстро включаются.
ОБНОВЛЕНИЕ: хотя большая часть того, как работает Deno, описана в этой статье и все еще актуальна, я бы теперь рекомендовал использовать Deno VSCode plugin от justjavac. Они проделали отличную работу!
В Deno v0.3.0 произошло несколько изменений, которые я отражаю в этой истории.
Я уже некоторое время работаю над Deno и начал создавать чуть более сложные приложения поверх него.
Для тех, кто может не знать о Deno, Райан Даль (первоначальный автор Node.js) и Берт Бедлер (основной участник Node.js и соучредитель Strong Loop) запустили Deno. Райан выступил с докладом на JSConf EU, подчеркнув 10 вещей, которые, по его мнению, он сделал не так с Node.js. Решение интегрировать компилятор TypeScript непосредственно в среду исполнения вызвало у меня большое любопытство, поэтому я засучил рукава и начал вносить свой вклад. Достигнут большой прогресс, хотя временами он кажется медленным, но он становится чем-то особенным.
Некоторое время я выбрал редактор Visual Studio Code. Первоначально меня привлекла его сильная поддержка TypeScript (которая также была построена с использованием TypeScript), но эта быстрая эволюция опыта действительно сделала меня более чем комфортным. Таким образом, полная поддержка Deno в среде IDE была для меня основной необходимостью, и, вероятно, отсутствие интегрированного опыта будет препятствием для принятия.
Deno дает Visual Studio Code (а язык TypeScript поддерживает intellisense) пару проблем. Во-первых, у Deno другая библиотека типов времени выполнения, чем у браузера (это то, что поставляется с TypeScript в lib.dom.d.ts) и, конечно же, Node.js ’(который доступен на npm как @types/node). Вторая проблема заключается в том, что Deno хочет быть полностью явным в идентификаторе модуля, что означает, что идентификаторы модулей требуют расширения. Поскольку Deno предпочитает TypeScript в качестве языка разработки, подавляющее большинство модулей заканчиваются на .ts, который по разным причинам TypeScript решил не поддерживать в настоящее время (в основном потому, что они никогда не предполагали среду выполнения, которая поддерживала бы TypeScript напрямую, и поэтому расширение .ts на файл будет ошибкой разработчика, потому что во время выполнения он, скорее всего, будет .js). В-третьих, Deno избегает любого внешнего менеджера пакетов или метаданных пакетов. Таким образом, удаленные модули автоматически загружаются и кэшируются локально для вас. Это означает, что Visual Studio Code изначально не знает, где искать эти удаленные модули.
Мы собираемся обсудить, как интегрировать Deno в VSCode ниже…
Типы времени выполнения
Двоичный файл Deno знает библиотеку типов среды выполнения, по которой он будет оценивать код. Эта библиотека типов встроена и может быть выведена в стандартный формат с помощью флага --types. Чтобы получить доступ к Visual Studio Code (в настоящее время), вам нужно будет разместить его где-нибудь, где языковые службы могут его найти:
$ deno --types > lib/lib.deno_runtime.d.ts
Вам также понадобится tsconfig.json, чтобы сообщить языковым службам в VSCode, как это найти. Мы также собираемся воспользоваться возможностью, чтобы настроить еще несколько значений по умолчанию, чтобы Visual Studio Code интерпретировал вещи более в соответствии с тем, как Deno будет их интерпретировать. В настоящее время Deno не поддерживает изменение параметров компилятора через tsconfig.json, но надеемся, что это произойдет в ближайшем будущем. Вот пример, который можно поместить в корень вашего проекта и, как правило, он будет работать и имитировать настройки внутри Deno:
{
"compilerOptions": {
"allowJs": true,
"esModuleInterop": true,
"lib": ["esnext"],
"module": "esnext",
"moduleResolution": "node",
"noEmit": true,
"pretty": true,
"resolveJsonModule": true,
"target": "esnext"
},
"include": [
"./**/*.ts"
]
}
Теперь по умолчанию Visual Studio Code сможет проверять типы ваших модулей на соответствие библиотеке времени выполнения Deno так же, как это делает Deno.
Разрешение модулей с расширениями .ts
Компилятор TypeScript и языковые службы не позволяют указывать спецификаторы модуля, заканчивающиеся на .ts. Как упоминалось выше, для этого есть разные причины, но большая часть из них связана с тем, что команда TypeScript не хочет переписывать спецификаторы модуля во время компиляции. Он ожидает, что все, что загружает модули, выяснит это. Кроме того, поскольку TypeScript предполагает, что среда выполнения изначально не поддерживает TypeScript, все, что заканчивается на .ts, на самом деле не будет заканчиваться этим во время выполнения. Поэтому, поскольку спецификатор модуля не будет перезаписан, предполагается, что все, что заканчивается на .ts, не будет работать во время выполнения.
Deno заняла твердую позицию в отношении явного использования спецификаторов модулей. Он не поддерживает какое-либо волшебное разрешение модуля, спецификатор - это спецификатор. Если ресурсы заканчиваются на .ts, тогда спецификатор модуля должен заканчиваться на .ts. Поскольку Deno предоставляет встроенный TypeScript со службами, необходимыми для разрешения модулей, внутренний TypeScript никогда не жалуется на эти ресурсы, он просто предполагает, что если Deno может разрешить его, все в порядке.
Таким образом, эти две концепции конфликтуют друг с другом при использовании языковых служб TypeScript в редакторе, таком как Visual Studio Code. TypeScript просто будет жаловаться, что любой модуль, заканчивающийся на .ts, неправильный, но Deno не разрешит модуль, если вы не укажете его расширение. Хорошей новостью является то, что TypeScript уже некоторое время поддерживает плагины языковых служб. Поэтому я написал плагин, который заменяет логику разрешения модулей для языковых служб аналогично тому, как работает Deno. Он называется deno_ls_plugin.
Чтобы заставить его работать в Visual Studio Code, вам нужно сделать несколько вещей. Во-первых, вам необходимо установить плагин в месте, где он может быть найден языковыми службами TypeScript. Кроме того, встроенная версия TypeScript в Visual Studio Code не сможет разрешить плагин, поэтому вам нужно будет установить TypeScript и указать VSCode использовать локальную версию. В-третьих, вам нужно будет указать VSCode использовать плагин.
В Deno нет ни централизованного диспетчера пакетов, ни метаданных / конфигурации package, но TypeScript разрешает плагин с помощью Node.js, поэтому, хотя он нам не нужен для Deno, нам нужно будет использовать npm или yarn для установите плагин и TypeScript:
$ npm install typescript deno_ls_plugin
Or:
$ yarn add typescript deno_ls_plugin
Для Deno (или кого-либо еще) не имеет значения, есть у вас package.json или нет. По умолчанию npm не будет создавать его, но yarn будет.
Затем вам нужно будет указать Visual Studio Code использовать локально установленную версию TypeScript:
Наконец, вам нужно сообщить TypeScript, чтобы использовать плагин. Это делается путем добавления плагинов в файл tsconfig.json:
{
"compilerOptions": {
"allowJs": true,
"esModuleInterop": true,
"lib": ["esnext"],
"module": "esnext",
"moduleResolution": "node",
"noEmit": true,
"plugins": [ { "name": "deno_ls_plugin" } ],
"pretty": true,
"resolveJsonModule": true,
"target": "esnext"
},
"include": [
"./**/*.ts"
]
}
Если у вас работает Visual Studio Code, вам, вероятно, придется перезапустить, чтобы изменения вступили в силу, но теперь при редактировании в VSCode вы сможете получить intellisense для своего импорта, и редактор будет отражать, как ваш код будет интерпретироваться в время выполнения.
Важно отметить, что import * as foo from "./foo" будет по-прежнему действителен в Visual Studio Code, но Deno выдаст ошибку. Вы должны быть откровенны и делать import * as foo from "./foo.ts".
Intellisense для удаленных модулей
Последний кусочек головоломки - создание intellisense для удаленных модулей. Службы языка TypeScript не будут запускаться и загружать удаленные модули за вас, в то время как Deno отлично поддерживает import * as foo from "https://example.com/foo.ts". Опять же, хорошая новость заключается в том, что мы можем указать языковым службам TypeScript искать ресурсы где-нибудь в локальной файловой системе. Хотя он не будет загружать их для вас, после того, как вы запустите свое приложение в deno и удаленные модули будут извлечены, они будут кэшироваться локально, и вы можете указать TypeScript на этот кеш. Это достигается с помощью параметра компилятора paths. По умолчанию Deno использует локальный кеш, который является стандартным местом для файлов кеша в операционной системе. В MacOS это ~/Library/Caches/deno, а в Linux - ~/.cache/deno. Подробности можно найти в Руководстве пользователя Deno. Проблема в том, что TypeScript может разрешить только paths относительно параметра компилятора baseUrl. Вам нужно будет снова настроить tsconfig.json, добавив paths и baseUrl:
{
"compilerOptions": {
"allowJs": true,
"baseUrl": ".",
"esModuleInterop": true,
"lib": ["esnext"],
"module": "esnext",
"moduleResolution": "node",
"noEmit": true,
"paths": {
"http://*": ["../../Library/Caches/deno/deps/http/*
"],
"https://*": ["../../Library/Caches/deno/deps/https/*
"],
},
"plugins": [ { "name": "deno_ls_plugin" } ],
"pretty": true,
"resolveJsonModule": true,
"target": "esnext"
},
"include": [
"./**/*.ts"
]
}
Скорее всего, вам придется снова перезапустить Visual Studio Code, если он у вас запущен.
Наконец-то…
Когда все будет готово, вы сможете получить полный опыт разработки в Visual Studio Code for Deno, воспользовавшись всеми преимуществами интеллекта как встроенной среды выполнения для Deno, так и любых удаленных модулей, которые вы включаете в свой пакет.
Я стараюсь сохранить все свои знания и следовать установленным соглашениям и шаблонам для Deno в примере проекта на GitHub под названием deno_example.
Кроме того, Амир Джан создал плагин VSCode, который автоматизирует эти вещи, которые вы, возможно, захотите проверить: deno-vscode.
