Вы правда считаете, что npm может ставить пакеты только из какого-то одного места, а не откуда угодно, включая кастомные npm-репозитории, git, локальную файловую систему, ssh, локальные tar.gz-архивы и удаленные tar.gz-архивы + бесконечное количество мест, добавляемых плагинами? Для многих путей, откуда npm может пакет поставить, даже URL нет, только URI от силы.
Только вот явно это не сделать, не так ли? Потому что импорт может произойти где угодно, включая вызов await import(generateSomeUrl()). А это значит, что нужно запустить где-то deno-поделку, дать поработать, собрать кэш, перебросить на сервер без интернета. Что исключает сборку артефактов на том же CI.
Мой нынешний проект работает как раз на airgapped серверах, где деплой выглядит следующим образом — специальный человек с флешкой проходит через сканирование сетчатки, после чего в пустой комнате с ноутбуком, подключенным к внутренней сети, сливает rpm-пакет на нужный сервер, забирает логи и уходит. Как собирать этот rpm, если "дать поделке поработать локально" не выйдет из-за того, что часть систем, к которым нужно подключаться, доступны только изнутри банка?
Главное чтобы возвращаемые структуры были идентичными.
Вот это как раз никто и никому не обязан. В версии 1 будут одни приватные поля, в версии 2 другие. Так как приватные поля не являются частью публичного АПИ, авторы их могут менять даже в минорных версиях по своему усмотрению. Будет ли работать новый код со старыми полями? Будет ли работать старый код с новыми полями? Ответ очевиден всем, кроме апологетов deno.
И еще легче ловить крайне стремные баги, вызванные несовместимостью внутренних структур того же moment, которые не являются частью публичного API surface, при передаче их между разными файлами проекта. Ведь это так забавно — иметь в половине проекта объекты одной версии, а в другой половине объекты другой версии, с неопределенным поведением при их взаимодействии.
Ах да, интереса ради проверил. В node 10.0.0, выпущенной 2 года назад, 1 мая 2018, поддержка top level await уже есть. Deno появился 13 мая 2018, и так за два года и не стал нужен хоть кому-то.
Можно еще сделать статический файл, в котором указать эти версии, а загрузчик с учетом версионирования встроить в рантайм. Назвать это как-то типа dependency.json, или я не знаю, package.json.
будто 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. Очередная поделка, призванная собрать все костыли и грабли заново. Надеюсь на скорое удаление репозитория deno как очевидно неудачного эксперимента.
А почему вы так уверены, что после введения вакцины вы не получите удаленный приказ отменить страховку или изменить получателя страховых выплат? И откуда вы только лезете?
Наверное, каждая девушка знает, что не стоит подбирать купленные отдельно юбку и кофточку при люминесцентном освещении, в надежде, что они подойдут друг другу при естественном, хотя и не знает, почему.
Ну правильно, откуда ж им, глупеньким, такое в принципе знать?
"ну да, ну да, пошел я нахер".
Вы правда считаете, что npm может ставить пакеты только из какого-то одного места, а не откуда угодно, включая кастомные npm-репозитории, git, локальную файловую систему, ssh, локальные tar.gz-архивы и удаленные tar.gz-архивы + бесконечное количество мест, добавляемых плагинами? Для многих путей, откуда npm может пакет поставить, даже URL нет, только URI от силы.
О какой централизации npm идет речь?
Только вот явно это не сделать, не так ли? Потому что импорт может произойти где угодно, включая вызов
await import(generateSomeUrl()). А это значит, что нужно запустить где-то deno-поделку, дать поработать, собрать кэш, перебросить на сервер без интернета. Что исключает сборку артефактов на том же CI.Мой нынешний проект работает как раз на airgapped серверах, где деплой выглядит следующим образом — специальный человек с флешкой проходит через сканирование сетчатки, после чего в пустой комнате с ноутбуком, подключенным к внутренней сети, сливает rpm-пакет на нужный сервер, забирает логи и уходит. Как собирать этот rpm, если "дать поделке поработать локально" не выйдет из-за того, что часть систем, к которым нужно подключаться, доступны только изнутри банка?
Правильно, никак.
Вот это как раз никто и никому не обязан. В версии 1 будут одни приватные поля, в версии 2 другие. Так как приватные поля не являются частью публичного АПИ, авторы их могут менять даже в минорных версиях по своему усмотрению. Будет ли работать новый код со старыми полями? Будет ли работать старый код с новыми полями? Ответ очевиден всем, кроме апологетов deno.
И еще легче ловить крайне стремные баги, вызванные несовместимостью внутренних структур того же moment, которые не являются частью публичного API surface, при передаче их между разными файлами проекта. Ведь это так забавно — иметь в половине проекта объекты одной версии, а в другой половине объекты другой версии, с неопределенным поведением при их взаимодействии.
Или ограничим API каждого модуля строго JSONами?
С умом выбираешь стабильные версии раз и навсегда, и дублируешь их 100500 раз в каждом файлике?
DRY это не про deno?
Развитие продукта это не про deno?
Детерминированные билды это не про deno?
Ах да, интереса ради проверил. В node 10.0.0, выпущенной 2 года назад, 1 мая 2018, поддержка top level await уже есть. Deno появился 13 мая 2018, и так за два года и не стал нужен хоть кому-то.
Можно еще сделать статический файл, в котором указать эти версии, а загрузчик с учетом версионирования встроить в рантайм. Назвать это как-то типа dependency.json, или я не знаю, package.json.
С той поделкой, которую автор пихает в любую жопу без спроса, $mol. Как раз будут два сапога пара — ненужный рантайм и никудышний фреймворк.
Какая глупость написана.
используются дольше, чем существует deno.
будто npm не скачивает пакеты и не кэширует их в node_modules? или будто npm не дает ставить пакеты откуда угодно, включая приватные гит-репозитории, локальные файлы и записную книжку вашей бабушки.
наверное, скачивание пакета и запись его в кэш у deno как-то особенно быстрее, чем скачивание пакета и запись его в кэш у npm.
в Node встроена поддержка любой версии Typescript, Flow, Hegel или еще неизобретенного тайпчекера с произвольными настройками.
Не говоря уже о том, что этой фиче сто лет в обед.
Ну конечно, ведь в ноде совершенно нет fetch, и никак не решен этот чудовищный недостаток. А вот зачем в ноде был бы нужен целиком DOM? Подозреваю, что авторы deno не осилили убрать из хромиума всю DOM-обвязку, поэтому сделали вид, что это фича.
Нет, конечно же.
Правда? https://nodejs.org/api/wasi.html
Ну а у ноды стандартная библиотека пустая совершенно.
Пять с плюсом отличных причин не использовать deno. Очередная поделка, призванная собрать все костыли и грабли заново. Надеюсь на скорое удаление репозитория deno как очевидно неудачного эксперимента.
Дмитрий, еще немного и у вас совсем не останется виртуалов.
отреверсил, там вся магия сосредоточена в
PsRegisterPicoProvider.Эту чушь уже где-то постили раньше… А, да, вот, нашел https://habr.com/ru/post/248147/
Похоже, что вы не сделали выводов из сильно отрицательного рейтинга прошлого аккаунта, не так ли?
Ну правильно, откуда ж им, глупеньким, такое в принципе знать?
Если сам lxss не вшит в ядро намертво, а является драйвером, то было бы интересно его отреверсить и хотя бы посмотреть, как он с ядром говорит.
А зачем же вы это пишете мне? Убеждайте george3, это у него все ему сплошную ерунду пишут, а разметки никакой нигде отродясь не было :)
Это WSL2, он скучный и обычная виртуалка. WSL1 куда интереснее с технической стороны.
А сейчас?