Комментарии 143
В среде Deno пакеты импортируются с использованием URL.
Главная причина того, что JS-разработчики НЕ будут использовать Deno. Вот психанёт разработчик условного leftpad и удалит сайт/репозиторий — и всё, нету вашего URL.
Ну или все будут импортировать с какого-нибудь npmjs.com или того же deno.land и в итоге по сути ничего не поменяется.
Вот психанёт разработчик условного leftpad и удалит сайт/репозиторий, а у вас в вашей репе лежит форк этого пакета.
Я задолбаюсь форкать все 2073 пакета, которые прописаны в зависимостях одного из моих небольших проектов.
Не надо ничего форкать, любой прокси решает эту проблему. Такой "прокси" могут даже встроить в сам Deno, и тогда он даже не будет иметь ничего общего с перехватом сетевых вызовов.
URL — это точно такая же виртуальная сущность, которая может указывать куда угодно. То, что пока его не отвязали — это просто свидетельство, что проблемы никакой нет. Слишком мало людей ещё пользуются Deno, есть проблемы важней.
Тем более, что Deno не нужно "пользоваться" прямо сейчас, это же фан-проект в самом разгаре разработки
URL в качестве виртуальной сущности окончательно теряет всякий смысл
Вы б рассказали, почему, что ли
Потому что в итоге получается тот же самый Node, в котором импорты тоже можно сделать с такими же виртуальными сущностями. Только будет хуже чем в Node, потому что через несколько итераций легаси придётся поддерживать совместимость с длинными неуклюжими URL из Deno v1.0
Дальше строго имхо, Райану свечку не держал.
Весь прикол в том, что Deno хорош для быстрого прототипирования.
Так-то, в C# и Java инструменты пофичастее будут, чем JS. И программы быстрей, стабильней, держат большую нагрузку. Но кто захочет связываться с жирными сложными чудовищами, если есть чудесный JS, где веб-сервер пишется в одну строчку в пустом файле? Весь поинт в этой невыразимой лёгкости использования, по сравнению с монстрами из Старого Мира
Имхо, тут — следующий шаг, улучшающий скорость прототипирования. Совершенно очевидно, что людям в среднем наплевать на то, чтобы думать о будущем, и строить правильные доверенные иерархии пакетов.
У человека есть мгновенная проблема — и он её решает методом копипасты с GitHub. Есть приложения, в которых нет почти ни одной своей строчки, это целиком готовые модули (возможно, свои с других проектов), копипаста с GitHub и StackOverflow и клей.
Поэтому важно, чтобы основной юзкейс использования (быстро навернуть готового кода откуда-то из произвольного места в интернете) был доступен за 0 секунд без включения мозга.
Вот у тебя есть какой-то другой проект, вчера ты его кодил. Ты хочешь, чтобы один из модулей, которые ты там наговнокодил, перекочевал в то, что ты пишешь прямо сейчас. Что для этого нужно сделать? Запушить старый говнокод в произвольное место на гитхабе в любом виде, какой тебе больше нравится, и прописать путь до него в import, всё
А вот все остальные кейсы, вроде поддержки срача из модулей через пять лет разработки — это уже всё дело десятое и инструменты для этого могут использоваться куда сложнее, или даже быть непрятными и уродливыми.
Пример уродливого, но рабочего решения — это файл-роутер, в котором можно сказать: "пакет по этому URL отвалился, будем использовать вместо него пакет по другому URL". Всё, починиль.
Один фиг, в нашем мире throawayware, скорей всего никакой код пять лет не проживёт, зависимости изменятся сто пятьсот раз совершенно не по причине того, что они сломались в репозитории, и беспокойство совершенно преждевременное :)
Весь прикол в том, что Deno хорош для быстрого прототипирования.
…
Но кто захочет связываться с жирными сложными чудовищами, если есть чудесный JS, где веб-сервер пишется в одну строчку в пустом файле?
…
У человека есть мгновенная проблема — и он её решает методом копипасты с GitHub. Есть приложения, в которых нет почти ни одной своей строчки, это целиком готовые модули (возможно, свои с других проектов), копипаста с GitHub и StackOverflow и клей.
Ох уже эти времена старого php… Только код брался, если правильно всё помню, из комментариев к официальной документации.
Вы думаете, что в js таки решил проблему, что код не пишется дважды?
Если уж надо тяп ляп, то заливать на github явно сложно, долго. Проще код копипастнуть у себя же на машине.
Меня больше беспокоит, одна библиотека будет импортировать leftpad с npmjs.com, другая с deno.lend, третья со своего сайта, в результате в проекте будет 3 копии одной библиотеки. А писать полный адрес каждый раз при импорте — то ещё развлечение.
Выглядит как нескучные обои:
- ECMAScript modules are the official standard format to package JavaScript code for reuse. Modules are defined using a variety of import and export statements.
- Как сказал предыдущий комментатор: внешние зависимости на проде — это нескучно!
- ts-node
- Experimental top-level await
- Давайте вместо Node и Deno сделаем новый проект с встроенным leftpad — Endooo!
При использовании Deno разработчик больше не привязан к NPM.
И где же здесь удобство?! Если у пакета сотни зависимостей — все прописывать в import?!
В Deno можно использовать await где угодно, организуя таким образом ожидание поступления каких-нибудь результатов. Помещать await-конструкции в async-функции необязательно.
А вот это очень полезно!
nodejs.org/api/esm.html
Может подождать полгода вместо перехода?
4.
nodejs.org/api/esm.html#esm_experimental_top_level_await
Думаю те же полгода
5.
А зачем на сервере window?
Fetch еще понятно, остальные не особо
Может подождать полгода вместо перехода?
За эти полгода в Deno появится ещё куча фичей.
Кажется, сейчас суть в том, что Deno идёт по переднему краю платформы и там есть и всегда будет всё то, что в node добавлять нельзя хотя бы потому, что будут ныть любители легаси. Не в смысле легаси "ой, апи поменялось в новой ноде", а легаси фундаментальных подходов к использованию
А зачем на сервере window?
Чтобы вы могли скопипастить кусок кода, изначально написанного для работы в браузере, и использовать и там и там без изменений. Например, раньше какой-то рендеринг или вычисление делалось на клиенте, и вы решили перетащить его на сервер.
Через пару лет, когда у deno будет свой легаси, пыл поубавится.
Тогда будет самое время придумать какой-нибудь edon.
И в спеках описан globalThis для написания кода как раз для разных движков.
в спеках-то он описан, но что делать с тонной программистов и их кода, которое ни про какие такие спеки не знает и продолжает использовать window. Если window есть, то всё это отлично работает
Можно примеры?
Легко. Приходим в Node и говорим, что JS файлы больше не обрабатываются, только TypeScript, кто не согласен — выметайтесь. Крик поднимется до небес.
пыл поубавится.
или не поубавится, потому что Deno — это площадка для экспериментов, и кто не согласен адаптироваться под новшества — идут на выход
раньше какой-то рендеринг или вычисление делалось на клиенте
дернул сервис с chromeless да и все быстро отрендерилось как надо. Нафига это включать в ядро? Оно далеко не всем надо на беке. Выглядит сомнительно.
Ну например (если речь про fetch) вы собираете запрос на другое АПИ, а у него свои правила, и приходится и в get параметры и в multipart/form-data, а тогда наличие URLSearchParams и FormData сильно упрощают работу. Конечно, для многих глобальных методов есть npm-пакеты, но многие не реализованы полностью.
5 главных причин того, что JS-разработчики будут использовать Deno вместо Nodeстатья:
Станет ли Deno, в итоге, заменой Node? Возможно.Вывод: заголовок кликбейтный.
А механизм import загружает модули в асинхронном режиме...
А как обеспечивается в редакторах автодополнение свойств, методов и пр., если модуль еще не загружен и неизвестно что там?
Один раз в сто лет появляется статья
Хабр: " теперь каждый день будут нам доказывать!!!"
Скорее как пропаганда Svelte. Что в общем, недалеко от религии.
Не знаю, меня никто не склоняет (в виде статей) срочно переходить на React/Vue/Angular, но очень яростно это делают в статьях о Svelte без особых на то причин/киллер-фич. По крайней мере на Хабре.
Да, о тройке больше статей, но не агитационных.
Сколько статей про Svelte не читал, ни разу не видел, что "нужно срочно переходить на Svelte". И вообще я не очень понимаю, как можно склонить перейти на Svelt в статье? Рука с пистолетом из монитора вылезает что ли? =)
Да, о тройке больше статей, но не агитационных.
Серьёзно? Стоит написать в поисковике: "{ framework1 } vs { framework2 }" или "why { framework1 } is better than { framework2 }" (framework1 и framework2 — любой из "тройки"), так сразу море статей найдётся. А что же творилось на релизах первых версий… И ладно статьи, так ещё и куча конференций, на которых хотя бы кто-то один из "тройки", но будет обязательно.
Надо совместить deno со svetle
Был я на докладе автора проекта. С его уст — это не замена node, пока еще все под вопросом. Он хочет решить ряд проблем которые лежат в основе node, но не стоит халиварить на тему node vs deno. Это по пока еще разные вещи.
ts-node нужен для разработки, а не для реальной эксплуатации.
Никто в Java не деплоит уже многоминутные war-контейнеры. JavaEE официально сдохла, вместо неё JakartaEE, которая только набирает силу, и в Jakarta относятся к "многоминутным war" крайне отрицательно.
JVM умеет подсасывать изменения на лету, приложение не нужно перезапускать. Если писать в определённом стиле и с использованием Spring, процесс ещё более приятный, чем на Ноде, потому что после подгрузки нового кода у тебя не теряется shared mutable global state.
В смысле, я не спорю с идеей fast loop, а исключительно с тем, что вы тут обосрали Java и C++. Или мне только показалось, что это был наезд? Если так, сорри. (Хотя у C++ всё ещё плохо, но начиная со стандарта 2020 года там появились модули, и всё стало сильно лучше)
Если же по существу, то я в курсе, что в Java есть механизм hot swap (тот, который в Идее навешен на Ctrl-F10), и очень рад этому факту. А особенно круто, что можно в отладчике дропнуть фрейм, и придти уже в обновленный код. И таким образом значительной части «многоминутных деплоев» можно избежать. Но, насколько я понимаю, существуют ограничения JVM для этого подхода: нельзя менять сигнатуру методов или удалять их. Если вы, как эксперт по Java, подсветите этот момент (или, может быть, даже подскажете, как их можно обойти), буду признателен.
Абстрактно говоря, в API JVM есть интерфейсы и для изменения сигнатур методов.
Просто в самой распространённой JVM (HotSpot) по этим интерфейсам находится
throw new UnsupportedOperationException();
Есть другие реализации JVM (как правило, платные), где есть полноценная поддержка смены сигнатур методов (так как метод полностью определяется через сигнатуру, поддержка смены сигнатур это синоним поддержки добавления/удаления). Потому для ускорения цикла ставят на машины разработчиков эти альтернативные JVM, а в бой всё идёт на HotSpot.
package-lock.json и прокси npm c кэшированием и проверками — это залог успешных билдов и ребилдов в ci/cd у ноды, а в дено это червь подсунутый в очередной зависимости только для продакшенфлоу билдера или рандомные ошибки сборки, потому что часть интернета опять полегла?
Спасибо, дайте два :)
import { moment } from "https://deno.land/x/moment/moment.ts"
Я не уверен что это хорошая идея. Ссылаться на последнюю версию библиотеки вот так, без страха и упрека — чревато ломающими апдейтами.
А хардкодить все версии зависимостей во всех файлах проекта, ну такое. Если у меня этот moment используется в 10 файлах в большом проекте, то в какой-то момент у меня неминуемо будет 10 разных версий moment.
У npm есть недостатки, конечно, но это знакомые, понятные недостатки.
Синтаксис URL:
https://deno.land/x/MODULE_NAME@BRANCH/SCRIPT.ts
Можно сделать бранчи по версиям, можно сделать бранч "stable", всё что угодно.
Строка импорта — это обычная строка, можно подсунуть туда имя нужного бранча интерполяцией, а само название бранча вписать в сеттинги.
И конечно, можно импортировать не с deno.land, а со своего собственного GitHub или CDN, на котором лежит истинно верный форк библиотеки. Возможно с вашими истинно верными патчами:
import { helloDeno } from "https://raw.githubusercontent.com/AbmSourav/deno-std/master/index.ts";
helloDeno()
А как потом во всем проекте обновить версию зависимости?
Как-нибудь так?
const moment = await import(`https://deno.land/x/moment@${Settings.Depenencies.MOMENT_VERSION}/moment.ts`)Или например, можно сделать свою репу на гитхабе, запушить туда Moment и ссылаться на этут репу. При необходимости изменить версию во всём проекте — идёшь на Гитхаб и заливаешь по этому адресу другую версию. Всё.
Вообще, Deno же развивается полным ходом. Туда можно припилить всё, что угодно.
Скорее будет использоваться файл deps.ts с реэкспортом:
export { moment } from `<URL>`;И тут мы возвращаемся к файлам, где объявлены все зависимости.
Хотя это, возможно, будет удобно, где нужно в зависимости от переменных окружения подсунуть другую реализацию модуля, для тестов, например.
А ничего, что вот этим Settings.Depenencies.MOMENT_VERSION вы фактически заново переизобрели package.json?
В принципе, можно создать файл dependency.ts и писать в нём:
export * as http from "https://deno.land/std@0.54.0/http/mod.ts";В таком случае версию пакета придётся писать только в одном файле и обновить можно будет в нём же
Можно еще сделать статический файл, в котором указать эти версии, а загрузчик с учетом версионирования встроить в рантайм. Назвать это как-то типа dependency.json, или я не знаю, package.json.
Напомнило фэнтези "Идущие в Ночь". Там у главной героини был боевой костюм типа скафандра, который расстегивался только у плечей, и снимать его было очень неудобно. Когда этот костюм выдавали, она поинтересовалась: "как же в нём срать" и получила ответ: "всё зависит от того, что ты чаще делаешь — дерешься или срёшь".
Вот и тут так. Всё зависит от того, что ты чаще делаешь — копипастишь какие-то URL с гитхаба на самую свежую версию либы, или с умом выбираешь стабильные версии.
С умом выбираешь стабильные версии раз и навсегда, и дублируешь их 100500 раз в каждом файлике?
DRY это не про deno?
Развитие продукта это не про deno?
Детерминированные билды это не про deno?
Я-то откуда знаю, что там про Deno, у меня имя не Райан Дал ;)
Выше есть сниппет кода — складываете истинно правильные версии в какой-то глобальный стор, потом используете плейсхолдеры с версиями при каждом импорте. Кстати, этот метод используется в Maven в Java — это такая платформа, где люди десятилетиями могут поддерживать совместимость кода, и за детерминированные сборки собачку родную убьют. Плейсхолдеры эти юзаются и в декларативных конфигах типа package.json (даже так — в основном в них и юзаются). Поэтому это было то, что первое пришло в голову — такое знакомое старое решение.
Я раньше программировал на Java и наелся всего этого дрожания над легаси, которое 20 лет работает без единого изменения. Лично мне гораздо удобней, чтобы у мнея было средство быстрого прототипирования, в котором о проблемах долгосрочной поддержки кода задумываться просто не нужно. Развалится — починим. Таков Путь.
То что я заметил в мире JS — разваливается обычно совершенно не от мифических ужасов с летфпадом, от которых тут все в шоке. А от того, что ты обновился на свежую не-LTS версию Ноды, которая вышла на прошлой неделе, а твои библиотеки ещё не обновились. Вот тут да, проблема.
Именно так) однако у вас всё ещё остаётся возможность использовать разные источники для пакетов ибо "децентрализованное хранилище пакетов". Конечно же в придачу и все вытекающие проблемы, вроде одного и того же пакета, что тянется разными зависимостями с разных урлов и т.д.
Вы правда считаете, что npm может ставить пакеты только из какого-то одного места, а не откуда угодно, включая кастомные npm-репозитории, git, локальную файловую систему, ssh, локальные tar.gz-архивы и удаленные tar.gz-архивы + бесконечное количество мест, добавляемых плагинами? Для многих путей, откуда npm может пакет поставить, даже URL нет, только URI от силы.
О какой централизации npm идет речь?
Можно сделать бранчи по версиям, можно сделать бранч «stable», всё что угодно. Строка импорта — это обычная строка, можно подсунуть туда имя нужного бранча интерполяцией, а само название бранча вписать в сеттинги.
Принципиально ли это отличается от Git URLs as Dependencies в npm?
Вы, конечно правы. Но как мне видится идея в том, что у вас не весь ваш проект зависит от moment, а каждый отдельный модуль/файл зависит от moment конкретной версии. Я вижу в этом возможность очень легко переводить обновление зависимостей в проекте по частям.
И еще легче ловить крайне стремные баги, вызванные несовместимостью внутренних структур того же moment, которые не являются частью публичного API surface, при передаче их между разными файлами проекта. Ведь это так забавно — иметь в половине проекта объекты одной версии, а в другой половине объекты другой версии, с неопределенным поведением при их взаимодействии.
Или ограничим API каждого модуля строго JSONами?
Сильно типизированными DTO. Не уверен, что это шутка.
Как мне кажется, это уже вопрос архитектуры. Если есть два независимых модуля, то один не должен ломаться при изменении реализации второго. Главное чтобы возвращаемые структуры были идентичными. А если два "модуля" сильно связаны между собой, тогда здравый смысл подсказывает, что они должны использовать общую версию зависимостей.
Главное чтобы возвращаемые структуры были идентичными.
Вот это как раз никто и никому не обязан. В версии 1 будут одни приватные поля, в версии 2 другие. Так как приватные поля не являются частью публичного АПИ, авторы их могут менять даже в минорных версиях по своему усмотрению. Будет ли работать новый код со старыми полями? Будет ли работать старый код с новыми полями? Ответ очевиден всем, кроме апологетов deno.
Ничего себе маленький сахарок.
Сейчас вот такое невозможно:
await Promise.resolve(console.log(''));
// → SyntaxError: await is only valid in async functionИ приходится писать так:
(async function() {
await Promise.resolve(console.log(''));
// →
}());При этом, например, если ты пишешь какой-то скрипт для командной строки на JS, то у тебя половина кода состоит из async-await-ов, потому что весь код скрипта исключительно синхронный, выполняется в один поток, и с таким подходом 30% кода — это слова "async" и "await".
Ещё как имеет, потому что все библиотеки имеют эвэйтовое API. Они не знают, что ты собираешься их использовать в одном треде.
Они не знают, что ты собираешься их использовать в одном треде.
Не знаю при чем тут треды… там тред один, не считая внутренних.
, тогда ее нужно будет подменить неявно на асинхронную
под "скриптом" я имею в виду то, для чего раньше использовали bash — всякая работа с файлами и запуском программ из командной строки. Или например, какие-то роботы, которые скрейпят чужие сайты в headless браузере. Или анализ данных и построение графиков в экселевском файле.
там у тебя нет асинхронности вообще. Каждую следующую строчку можно делать только если все предыдущие уже завершились. Как в баше и питоне, которые всё это и призвано заменить
ну и сейчас ты просто руками делаешь (async function() { }()), и дальше там скобочках происходит вообще весь текст скрипта. Туда же можно впилить верхнеуровневый try-catch. Получается прям аналог функции main из C++.
и дальше у тебя примерно каждая строчка в твоей программе начинается с await. Каждая. Ибо "промисифицированное апи" имеет каждая собака. Даже твой собственный код имеет такое апи, потому что ты писал его в предыдущем проекте для сервера, и там всё насквозь асинхронное.
Одно не понимаю. И что мешает сделать одну большую async функцию и вызывать её в таком скрипте? Зачем top level-то?
Очень утомляет каждый раз писать
(async () => {
await fs.readFile();
})().catch(error => {
console.error(error);
process.exit(1);
});В этой ситуации очень часто забывают про catch, а это важно.
С top-level await эти обертки становятся не нужны и работать намного проще.
Ну так это только если это ваш полный скрипт. Обычно он несколько больше, и ты один раз сделал верхнюю асинк функцию, а дальше спокойно внутри эвейтами обмазываешься.
В том и загвоздка, что это придется делать в каждом файле.
В случае приложения, сделать это в одном app.js не проблема, а вот делать это в каждом build-скрипте утомляет и легко ошибиться.
Поэтому и нужен не только top-level async, а everyting async. Это можно навертеть самостоятельно, конечно, есть же бабель и другие JS трансформаторы. Но это уже некий недостижимый уровнь для ситуации, когда тебе нужно наебашить тридцать скриптов за вечер — нет времени думать, делать надо.
Чё бы не писáть
const {users} = fetch(URL).json();Потому, что иногда имеет смысл ожидать результат позже
// Start downloading data in advance
const promise = fetch('/user')
// Do something very difficult and time consuming
heavy()
// Waiting for the data download to finish
const {user} = await promiseИли не ожидать результат вовсе
fetch('/signal') // No await
heavy()Дальше холиварненько по теме промисов, но всё же.
Вызов функции fetch интерпретатор расценивает как явное применение асинхронности. А последующее await для передачи значения в переменную выглядит подобно разыменованию указателя.
В случаях, когда важен именно статус исполнения, пусть будет стоять promise.
const {users} = fetch('/users');
// просто некая конструкция для получения именно промиса по какой-то переменной
let {status} = promise users;
//или то же самое но в форме привычной объективации переменной в конкретный тип
let {status} = Promise(users);
Какая глупость написана.
Современные возможности JavaScript: ES-модули
используются дольше, чем существует deno.
Децентрализованное хранилище пакетов
будто npm не скачивает пакеты и не кэширует их в node_modules? или будто npm не дает ставить пакеты откуда угодно, включая приватные гит-репозитории, локальные файлы и записную книжку вашей бабушки.
наверное, скачивание пакета и запись его в кэш у deno как-то особенно быстрее, чем скачивание пакета и запись его в кэш у npm.
В Deno встроена поддержка TypeScript
в Node встроена поддержка любой версии Typescript, Flow, Hegel или еще неизобретенного тайпчекера с произвольными настройками.
Поддержка await за пределами асинхронных функций
Welcome to Node.js v12.16.2.
Type ".help" for more information.
> async function foo() { return "hello" }
undefined
> await foo()
'hello'
> Не говоря уже о том, что этой фиче сто лет в обед.
Доступ к браузерным API (Window, Fetch)
Ну конечно, ведь в ноде совершенно нет fetch, и никак не решен этот чудовищный недостаток. А вот зачем в ноде был бы нужен целиком DOM? Подозреваю, что авторы deno не осилили убрать из хромиума всю DOM-обвязку, поэтому сделали вид, что это фича.
Например, Deno, в своём стандартном виде, безопаснее.
Нет, конечно же.
В среде Deno можно выполнять Wasm-код,
Правда? https://nodejs.org/api/wasi.html
тут имеется множество встроенных библиотек.
Ну а у ноды стандартная библиотека пустая совершенно.
Пять с плюсом отличных причин не использовать deno. Очередная поделка, призванная собрать все костыли и грабли заново. Надеюсь на скорое удаление репозитория deno как очевидно неудачного эксперимента.
Разбор по пунктам хороший, но вот последнее предложение резковато. Очень хорошо, что есть конкурирующий проект, который подстегивает инновации и в node.js тоже, потому что им теперь есть куда терять пользователей.
Ах да, интереса ради проверил. В node 10.0.0, выпущенной 2 года назад, 1 мая 2018, поддержка top level await уже есть. Deno появился 13 мая 2018, и так за два года и не стал нужен хоть кому-то.
Судя по тексту, вы похоже не в курсе, что автор у node и deno один и тот же.
А каким образом это влияет на написанное? Глупость написал не автор deno, а автор этого поста. И то, что у автора ноды получилось в первый раз сделать что-то хорошее, не дает гарантий того, что у него это получится во второй раз. Вот, deno тому ярким примером — хуже только php.
Подозреваю, что авторы deno не осилили убрать из хромиума всю DOM-обвязку, поэтому сделали вид, что это фича.(кстати, при чем тут хромиум вообще?)
Заголовок у статьи конечно кликбейтный, но все-равно ваш комментарий звучит так, будто deno сейчас кто-то сильно пиарит как «убийцу» nodе.
По сути это эксперимент, посмотреть на реакцию js сообщества.
К ноде многие уже просто сильно привыкли, на начальных этапах тоже очень много вопросов возникало.
Точно так же как и в случае с node: скачать все зависимости локально и закинуть на сервер папку с кэшем.
Только вот явно это не сделать, не так ли? Потому что импорт может произойти где угодно, включая вызов await import(generateSomeUrl()). А это значит, что нужно запустить где-то deno-поделку, дать поработать, собрать кэш, перебросить на сервер без интернета. Что исключает сборку артефактов на том же CI.
Мой нынешний проект работает как раз на airgapped серверах, где деплой выглядит следующим образом — специальный человек с флешкой проходит через сканирование сетчатки, после чего в пустой комнате с ноутбуком, подключенным к внутренней сети, сливает rpm-пакет на нужный сервер, забирает логи и уходит. Как собирать этот rpm, если "дать поделке поработать локально" не выйдет из-за того, что часть систем, к которым нужно подключаться, доступны только изнутри банка?
Правильно, никак.
Так, как бы, и встроенными инструкциями такое возможно
https://deno.land/manual/linking_to_external_code/integrity_checking
Создаст список всех зависимостей:
deno cache --lock=lock.json --lock-write src/entry.tsСкачает все зависимости и проверит каждую по хэшу
deno cache -r --lock=lock.json src/entry.tsНо проблема с динамическими импортами действительно есть.
Поправьте если я заблуждаюсь, но в 14 версии ноды есть поддержка es модулей (без загрузки по url)
1. Современные возможности JavaScript: ES-модули
Указываем в package.json
{
"type": "module"
}И спокойно пишем
import fs from 'fs'
import myModule from './myModule.js'
В среде Deno пакеты импортируются с использованием URL.
Это что получается, надо во всех модулчх проекта импортировать на URL, а при переходе на новую версию искать все включения и каждый раз в куче файлов обновлять URL зависимости? А что делать, если у проекта несколько зависимостей, которые зависят от разных версий одной и той же библиотеке?
Мне видится в этом больше преимущество. Как я понимаю в этом и весь прикол, что у вас нет списка зависимостей на весь проект. А каждый ваш модуль/файл имеет собственный набор зависимостей. И вы можете спокойно изменять зависимости в одном модуле не боясь сломать все остальные.
Вот представьте ситуацию:
Вам пришла задача, сделать какую-то фичу. Для вас это не проблема, вы нашли библиотеку "А" и хотите её использовать. Но вот проблема — в проекте уже применяется библиотека "А" причем версии "0.0.1" в старом многолетнем legacy. Имея такую систему как у Deno, вы об этом вообще можете не думать. Старый модуль будет использовать свою версию, а вы можете использовать свою.
Разве они позволяют разным модулям (не разным приложениям/пакетам) иметь разные версии одной зависимости? Только если выносить модули в пакеты отдельные. А в JS/TS сейчас модулем является практически любой файл с кодом.
нет, а зачем оно надо? на уровне пакетов должно быть достаточно
Ну вот надо мне создать новый модуль для системы, вижу что есть в мире библиотека, которая мне поможет, причём особенно помогут новые фичи последней стабмльной версии. В идеальном мире я просто беру её для своего модуля и не парюсь. В реальном она уже может использоваться в проекте и версия будет, скорее всего, не последняя. У меня дилемма — использовать имеющуюся версию, дублируя в своём модуле код, который есть в последней (копипаст или велосипед — не суть), или обновить зависимость во всём проекте с большим риском вызвать кучу ошибок. Ну ещё вариант — оформить мой модуль как пакет, получив все "прелести" разработки в нескольких местах. Все варианты приводят к дополнительной работе и в фазах разработки и тестирования, и, главное в фазе поддержки и, даже, вывода из эксплуатации.
Проекты работающие на js без интернета: УУУУУуууу кайф, спасибо Node что живой!
но куча потенциальных проблем на лицо!
Для нативных аддонов Deno ещё хуже чем NodeJS. В ноде можно обращения от нативного модуля к обёртке над v8 сократить, а в Deno все данные через обёртку обязаны проходить.
Для серверных задач из-за этого минуса просто бесполезен за пределами тестовых поделок. Не думаю что этот пункт "ради безопасности" изменится в Deno.
Оба проекта губят производительность движка v8. Первый хотя бы меньше.
Синтаксический сахар меня мало интересует. Может быть кому-то он и нужен.
Deno не является решением для продакшена и в этом смысле он не конкурент для node. Это proof of concept. По сути, маркетинг проекта больше направлен на то, чтобы найти энтузиастов и единомышленников для исследования возможностей предложенной архитектуры.
Слишком много внимания и громких заявлений ни о чём
Он сначала написал себе node.js, а потом уже node.js с ts
Так и сама node.js — история на любителя. "5 причин того, что бєкенд-разработчики будут использовать node,js вместо их любимых PHP/Python/Ruby/Java/C#/C++/..." куда более бурные обсуждения вызывали :)
А автор уже показал свою способность делать то, что востребовано очень многими. Вот недавно при смене проекта, узнал, что большинство вакансий "Фуллстэк разработчик" (без указания чегото-то типа PHP или Java) теперь подразумевают JS/TS на фронте и бэке — это буквально за год картина на рынке изменилась.
5 главных причин того, что JS-разработчики будут использовать Deno вместо Node