Comments 43
А в случае с deno — 5 раз загрузишь в новые проекты нужную тебе библиотеку, а на шестой раз окажется что тот сервер взломали, и ты подгрузил себе криптомайнер.
Хэш-суммы придумали не вчера.
А где в строчке import { assertEquals } from "https://deno.land/std/testing/asserts.ts"; вы видите хеш-сумму?
Речь про то, что вообще-то методы повышения доверия к скачиваемому непонятно чему непонятно откуда — вполне существуют.
ЗЫ: Ну и мысль заглавного коммента о том, что NPM «лучше» — она тоже заслуживает осуждения. Не лучше. Всё те же яйца.
Речь про то, что вообще-то методы повышения доверия к скачиваемому непонятно чему непонятно откуда — вполне существуют.Самый лучший метод повышения доверия к непонятно чему — не скачивать непонятно откуда.
Самый лучший метод повышения доверия к непонятно чему — не скачивать непонятно откуда.
Конечно. Но удобство скачивания настолько велико, что оно так или иначе никуда не денется; исключая случаи, где повышенный уровень недоверия просто необходим по предметной области.
Deno, как и браузеры, загружает модули по URLКак я уже писал и в прошлый раз, загрузка исходников по прямым ссылка фактически в рантайме — это умножение на 0 всех потуг в стабильность и безопасность.
Ну и до кучи, подгружать так можно только отдельно лежащий файл в вакууме. Ни зависимостей ни деклараций вы таким образом не получите.
В статье упоминается флаг --importmap, с помощью которого можно настроить маппинг коротких имен модулей на полноценные урлы. В таком случае в исходниках будут такие же как и сейчас import 'lodash';, а обновление версий будет происходить только в файле маппинга.
Более того, import-maps является кандидатом в веб-стандарты и уже имеется некоторый набор инструментов, чтобы генерировать import-maps из yarn.lock or package-lock.json
Deno декларирует совместимость с браузером в своих design goals, так что ничего удивительного в том, что они используют стандарт написанный для браузера.
В import-map есть возможность указать корневой путь сразу до всех файлов из модуля:
{
"imports": {
"lodash/": "/node_modules/lodash-es/"
}
}вот вам и импорт пакетов.
Deno декларирует совместимость с браузером в своих design goals,троллейбус_из_хлеба.jpg. В смысле, а нафига?
В import-map есть возможность указать корневой путь сразу до всех файлов из модуля:Да, именно файлов. Без собственных зависимостей, метаданных и неявно подгружаемых элементов. Для скомпилированных библиотек в браузере — понятно зачем. Для исходников на сервере — непонятно, а кому от этого будет польза.
То что это не нужно вам, это не значит что это не нужно никому.
Унификация браузерного и серверного кода позволить использовать любые библиотеки в своих проектах, а не только специальные "изоморфные".
Node.js тоже движется в этом направлении, например ввели глобальный класс URL совместимый с браузером, теперь думают над добавлением нативного fetch. Просто у node большой груз обратной совместимости с существующими модулями, поэтому там это не так революционно.
Унификация браузерного и серверного кода позволить использовать любые библиотеки в своих проектах, а не только специальные «изоморфные».
1. Подход Deno не расширяет возможности браузера до сервера, а сужает возможности сервера до браузера.
2. У сервера и браузера разный рантайм, большинство кода в принципе не сможет работать и там и там.
3. «Унификация» приведёт к несовместимости проектов Deno с node.js, что тоже мало кому надо.
Помимо флага --allow-write, влияющего на работу с файловой системой, при запуске скриптов можно использовать и другие флаги. Это — --allow-net, --allow-env и --allow-run
Если существует --allow-run то какой смысл в остальных флагах? Или я чего-то не понимаю? Если кто-то нехороший захочет дел натворить, разве --allow-run не будет достаточно?
Это же, разрешительный флаг, а не запретительный, в смысле детализация других "мелких" разрешений вполне законна. Не надо же сразу всем 0777 делать.
То есть достаточно создать злой пакет, который якобы служит для запуска какого-то процесса с определенными параметрами (в npm таких неимоверное множество), но под капотом он сможет делать вообще все что угодно, и это будет не отследить.
Если позиционировать себя как песочницу, то стоит идти в направлении докера, sandboxie и т. д. а не просто ограничить вызовы стандартной библиотеки.
Интресно было бы узнать о скорости работы нового решения, но всех только за импорты борются.
Это вполне могло бы сойти за тонкую первоапрельскую шутку.
import myFS from 'mysite.net/myFS'
console.log(myFS.readFromFile('anyfile'))
Доступ к файловой системе, доступ к сети и тп. Механизма контроля подключенных модулей я не увидел.
Вообще, изоляция на уровне контейнера типа докера выглядит более надежной
Ну что вы к менеджеру пакетов прицепились, он тут не важный...
Если новый http не будет лучше сделан, чем у ноды, то этот движок не кому не нужен будет.
В текущей ноде проблема в медленном парсере, парсит все, даже когда это вам не нужно. Дино наступает на те же грабли.
Кстати след релиз ноды будет через 3 месяца. В этом должны выпустить tls для 12, по крайней мере было обсуждение.
blog.logrocket.com/node-js-12
Я понимаю ещё, если бы она была быстра как пуля и надежна как сундук с баксами, но судя по всему это совсем не так.
Что такое Deno и чем этот проект отличается от Node.js?