Pull to refresh

Comments 26

UFO landed and left these words here
Очень странное решение, ибо так вы отдаёте всё наружу, не разделяя на публичное и приватное
UFO landed and left these words here
лучше бы разработчики node.js сделали всё открытое, а кому уже нужно закрывать, те бы писали private перед переменными.

так уже было изначально в браузерах, когда функция, объявленная в одном тэге script была доступна в другом. Такой подход оказался очень неудобным, и разработчикам пришлось изощряться, чтобы создать себе приватную область видимости. Полностью эта история рассказана в этой статье.


Поэтому текущий модульный подход с необходимостью писать явный export оказывается лучше и удобнее для большинства разработчиков. Мы изначально высвечиваем из модуля его публичное API, а потом уже модифицируем его внутри как хотим, и нам не нужно писать private каждый раз, когда мы рефакторим и создаем внутри новые функции и переменные.

UFO landed and left these words here
Ваше предложение сделать все открытым для импорта по умолчанию страдает от той же проблемы, что и до-модульный Javascript с глобальной областью видимости. Очень легко ошибиться и нечаянно оставить открытыми функции, которые не предназначались для использования снаружи.

Именно поэтому, на опыте прошлых ошибок, JS-модули сделаны с явным экспортом, чтобы не было случайных утечек приватных функций
оставить открытыми функции, которые не предназначались для использования снаружи.

Это мелочи. Гораздо хуже то, что засоряется глобальное пространство имён. Приходится вводить префиксы, чтобы модули не конфликтовали.
UFO landed and left these words here
я должен писать список ещё и при экспортировании.

А я ещё и комментарий пишу с рекомендуемым способом импортирования этого модуля.
Потому что это удобнее, чем каждый раз вспоминать, что и под какими именами из него импортируется.
[a-zA-Zа-яА-ЯёЁ_0-9] — имена перемеренных, констант, классов кириллицей?
Emoji и другие алфавиты не учтены.
Вот вы ржоте, а у нас некоторые клиенты хотят эмоджи во всяких странных и не предназначенных для этого местах :(
Еще перепишите автозамену let на const и сразу в продакшен заливайте, только заранее найдите новое место работы.
Зачем же перед каждой переменной и функцией писать export, если можно это сделать в конце файла?:

export {
  name1,
  name2,
  ...
}

UFO landed and left these words here
Меня очень бесит, что перед каждой переменной и функцией в модулях нужно писать слово export.

И правильно бесит, потому что не нужно так делать.

Экспериментально эта возможность была доступна с Node 8.0 с 0 фазы. Текущий релиз — это большой шаг в этом направлении

Неплохо было бы раскрыть, что именно произошло здесь. Попробую это сделать.


8 версия содержала в себе старую версию реализации. У этой реализации были недостатки, поэтому было решено переделать ее. Текущая версия является обладает новыми возможностями, например доступом к классическому require() из es-модуля.


Кроме этого, новая реализация позволяет использовать расширение .js для es-модулей (вместо специального .mjs), предлагая использовать поле "type": "module" в package.json, чтобы авторы npm-модулей могли сами определять, является ли их пакет es-модулями, или старыми commonjs

UFO landed and left these words here
Неужели это нельзя было зашить в интерпритатор? Пусть хоть там в ___x преодбразует какая разница. Просто язык превращается в набор символов, который нужно запоминать, а к реальности никакого отношения.
UFO landed and left these words here
С обратной совместимостью скорее никак, скорее тут надо вводить новое ключевое слово private как const, static на уровне интерпретатора.
Меня интересует, как обстоит с этим дело в TypeScript?
На данный момент, насколько я понимаю, не весь JS-код будет валидным для TS?
UFO landed and left these words here
Sign up to leave a comment.

Articles