Comments 16
Но ведь это замусоривание глобального неймспейса заранее неизвестными идентификаторами :(
Работать другим модулям это не мешает. Переопределение любой переменной через
Другой вопрос, если в модуле используются заранее не определенные переменные. И алгоритм рассчитывает, что их значения заранее undefined. Но это не очень хорошая практика, и при использовании
let, const или var остается.Другой вопрос, если в модуле используются заранее не определенные переменные. И алгоритм рассчитывает, что их значения заранее undefined. Но это не очень хорошая практика, и при использовании
'use strict'-режима может вызвать runtime-ошибку.Кроме того, например, у меня в самом большом проекте их подключено таким образом максимум штук 40. Это количество включает в себя некоторые стандартные модули, используемые npm-модули и локальные модули.
И никто не заставляет прописывать их все. Профит получается уже с часто используемых «util», «fs» и «path».
В целом, вы правы. Практика немного сыровата. Пользоваться или не пользоваться — дело индивидуальное. Но статья имеет место быть. Надеюсь, и вы научились для себя чему-то новому. Или вам жалко времени, убитого на прочтение статьи?
И никто не заставляет прописывать их все. Профит получается уже с часто используемых «util», «fs» и «path».
В целом, вы правы. Практика немного сыровата. Пользоваться или не пользоваться — дело индивидуальное. Но статья имеет место быть. Надеюсь, и вы научились для себя чему-то новому. Или вам жалко времени, убитого на прочтение статьи?
Явное все-таки лучше неявного.
Вы правы. Но идеология распределения имен в node сама по себе не идеальна.
То есть, мы не против глобальных
Мы же не добавляем в шапку что-то вроде:
Почему разработчики node не сделали то же самое с модулем
Ведь сам
То есть, мы не против глобальных
console и process.Мы же не добавляем в шапку что-то вроде:
var console = require('console');
var process = require('process');
Почему разработчики node не сделали то же самое с модулем
util?!Ведь сам
util всегда загружен, и его методами активно пользуется та же console.Честно говоря, за несколько лет пользовался модулем util всего пару раз:) Я согласен, что как-то неконсистентно получается, но, с другой стороны, util — это, имхо, барахолка, сборник функций разного назначения, часть из которых устарела, часть deprecated, а часть нужна не каждый раз (готов аргументировать по каждому методу). Согласитесь, насильно пробрасывать эту барахолку в глобальный скоуп всем — как-то некомильфо.
Я думаю, если бы это было не так, этот вопрос давно бы уже подняли в сообществе и вынесли все нужное в глобальный скоуп.
Засорение глобального скоупа всегда потенцильно опасно. Через полгода выйдет ES2016, нет никакой гарантии, что в нем не появится глобальное имя util.
Я думаю, если бы это было не так, этот вопрос давно бы уже подняли в сообществе и вынесли все нужное в глобальный скоуп.
Засорение глобального скоупа всегда потенцильно опасно. Через полгода выйдет ES2016, нет никакой гарантии, что в нем не появится глобальное имя util.
Ну, если в ES2016 появится ключевое слово
или
А иногда даже неявное необходимо больше явного.
Например, если мы хотим заменить стандартный
Например, мы хотим, чтобы
С помощью
И, вообще связка
util, то, так и так придется переписывать исходники, будь то:var util = require('util');или
global.util = require('util');А иногда даже неявное необходимо больше явного.
Например, если мы хотим заменить стандартный
console собственным логгером.Например, мы хотим, чтобы
console.log() выдавал в stdout не только строку, переданную параметром, а еще путь к файлу и номер строки, откуда этот console.log() был вызван.С помощью
global и ключа node --require это можно сделать прозрачно для самой программы, т.е. не исправляя исходный код самой программы.И, вообще связка
global + --require, собственно, существует для расширения стандартных возможностей node.Ваш пример (да и вообще практически весь столь любимый вами модуль util) нужен исключительно для дебага. Для которого существуют и другие методы. Не говоря уж о том, что проще написать юнит-тесты, чем расставлять сотни console.log в надежде найти ошибку.
Вы преувеличиваете. Unit-тестами обычно покрывают свой исходный код, когда есть 100% понимание работы этого кода.
Например, я его часто использую, когда разбираюсь в чужих исходных кодах.
При этом, сами чужие коды работают без ошибок.
Можно, конечно, подключить отладчик к IDE и выполнять скрипт step-by-step.
Но такой режим не очень подходит для изучения чужих исходных кодов и очень утомителен.
console.log() не все используют только лишь в поиске ошибок.Например, я его часто использую, когда разбираюсь в чужих исходных кодах.
При этом, сами чужие коды работают без ошибок.
Можно, конечно, подключить отладчик к IDE и выполнять скрипт step-by-step.
Но такой режим не очень подходит для изучения чужих исходных кодов и очень утомителен.
Ну положим, вам так удобнее, не буду спорить. Ну а модуль util в процессе изучения чужого кода вам зачем?
Я, вроде бы, нигде не утверждал, что util нужен не в процессе изучения чужого кода.
В util использую чаще всего методы isArray(), isError() и проч.
На основе стандартного util, я его немного расширил, добавил методы isInt(), isGenerator() и проч., вот тот demandLoad() у меня util.demandLoad().
Еще пользуюсь util.inspect(), но это, опять же для дебага, в продакшене бесполезен.
Раньше пользовался util.inherits(), но он уже отходит с появлением классов в синтаксисе.
В util использую чаще всего методы isArray(), isError() и проч.
На основе стандартного util, я его немного расширил, добавил методы isInt(), isGenerator() и проч., вот тот demandLoad() у меня util.demandLoad().
Еще пользуюсь util.inspect(), но это, опять же для дебага, в продакшене бесполезен.
Раньше пользовался util.inherits(), но он уже отходит с появлением классов в синтаксисе.
util.isError
Вместо util.isArray с незапамятных времен есть стандартный Array.isArray, если что.
Вообще непонятно, зачем менять стандартное, если можно свое завернуть в модуль, положить на какой-нить гитхаб и счастливо юзать. npm — лучшее изобретение со времен нарезанного хлеба. Тем более там наверняка такого счастья уже навалом.
Как я уже говорил — util состоит из deprecated, ненужного и util.inspect/util.format, которые нужны, в основном, для дебага.
Stability: 0 — Deprecated
Вместо util.isArray с незапамятных времен есть стандартный Array.isArray, если что.
я его немного расширил
Вообще непонятно, зачем менять стандартное, если можно свое завернуть в модуль, положить на какой-нить гитхаб и счастливо юзать. npm — лучшее изобретение со времен нарезанного хлеба. Тем более там наверняка такого счастья уже навалом.
Как я уже говорил — util состоит из deprecated, ненужного и util.inspect/util.format, которые нужны, в основном, для дебага.
Про Array.isArray я в курсе. Как раз именно его util.isArray() использует в последних версиях.
Так, стандартное как раз я никогда не пытался заменить.
Самим node пользуюсь с версии 0.4.x. Могу, конечно, пропустить обновления в документации о deprecated-статусах.
Само использование util.isError() не выводит в stdout, что использую deprecated-функцию, в отличии от, например, util.exec(), который deprecated уже очень давно.
Ну а по поводу того, что расширил. Сами то исходники всего расширения в отдельном модуле. Так исторически получилось, что я назвал его util (можно было выбрать любое название). В работе просто подключаю его локально вместо стандартного util. В него стекались все простые функции абсолютно разного назначения, которых очень много. Чтобы не подключать букет всевозможных npm-модулей, все было собрано в один файл. Разумеется, ведь не в глобальный скоуп их подключать.
Выложил на pastebin
К сожалению, мы за деньги пишем пока только проприетарный код. Сами его используем. Сами разворачиваем. Сами поддерживаем. Ну, по разным понятным соображениям, публичным гитхабом пользоваться не стали. Недавно приняли решение об использовании приватного npm. Правда, дальше принятия решения дело не двинулось :) Ну, не до этого было.
Так, стандартное как раз я никогда не пытался заменить.
Самим node пользуюсь с версии 0.4.x. Могу, конечно, пропустить обновления в документации о deprecated-статусах.
Само использование util.isError() не выводит в stdout, что использую deprecated-функцию, в отличии от, например, util.exec(), который deprecated уже очень давно.
Ну а по поводу того, что расширил. Сами то исходники всего расширения в отдельном модуле. Так исторически получилось, что я назвал его util (можно было выбрать любое название). В работе просто подключаю его локально вместо стандартного util. В него стекались все простые функции абсолютно разного назначения, которых очень много. Чтобы не подключать букет всевозможных npm-модулей, все было собрано в один файл. Разумеется, ведь не в глобальный скоуп их подключать.
Выложил на pastebin
К сожалению, мы за деньги пишем пока только проприетарный код. Сами его используем. Сами разворачиваем. Сами поддерживаем. Ну, по разным понятным соображениям, публичным гитхабом пользоваться не стали. Недавно приняли решение об использовании приватного npm. Правда, дальше принятия решения дело не двинулось :) Ну, не до этого было.
Sign up to leave a comment.
Node.JS Избавься от require() навсегда