Никто не запрещает использовать NODE_PATH и добавить корень проекта. Общепринятая практика в сях/крестах (см гугловский стайлгайд), в питоне (пакеты) и в расте

основная проблема в том, что это контринтуитивно. когда я вижу require('some-module'), я думаю, что это какой-то внешний пакет, когда я вижу require(./../some-module) - то понимаю, что это что-то внутреннее.

Разве? https://github.com/nodejs/node/issues/1627#issuecomment-102528465

Да, просто soft deprecated

Там в треде есть

основная проблема в том, что это контринтуитивно. когда я вижу require('some-module'), я думаю, что это какой-то внешний пакет, когда я вижу require(./../some-module) - то понимаю, что это что-то внутреннее.

Это от незнания алгоритма поиска модулей

на вебшторм кстати неплохой плагин есть - commonjs autocomplete

основная проблема в том, что это контринтуитивно. когда я вижу require('some-module'), я думаю, что это какой-то внешний пакет, когда я вижу require(./../some-module) - то понимаю, что это что-то внутреннее.

Да, но если будет корень проекта, то будет что-то вроде require('app/models/some_super_model')

Это от незнания алгоритма поиска модулей

Нет, это де-факто практика такая, и тот же самый WS сейчас вообще игнорит node_modules

Можно ./ добавлять перед app :)

У тебя де-факто, а у меня фактически - алгоритм есть и он работает

Можно ./ добавлять перед app :)

Не будет работать же

Нет, это де-факто практика такая, и тот же самый WS сейчас вообще игнорит node_modules

Уже нет, позавчера патч вышел.

У тебя де-факто, а у меня фактически - алгоритм есть и он работает

Это не у меня де-факто, а у сообщества. И опыт WS это подтверждает.

Код VS сообщество

Сообщество-то какое? Верстальщики приемущественно))

Ладно, я не знаю о чём мы говорим. Покажи пример используемой библиотеки, где так используется node_modules, тогда будет о чём говорить.

И питонисты

Ладно, я не знаю о чём мы говорим. Покажи пример используемой библиотеки, где так используется node_modules, тогда будет о чём говорить.

+++

А кто с этим спорит) Я как раз наоборот подтверждаю явление. Но это не отменяет того, что причиной бомбежки является стадный инстинкт и нежелание читать код

А в чем проблема просто использовать require как положено?

А в чем проблема просто использовать require как положено?

Один из аргументов, который я слышал: "при переносе файлов внутри структуры проекта, придется везде менять относительные пути" :)

А как положено? Если механизм поиска модулей реализован в самом require и я использую это, почему вдруг это стало "не положено".

Потому что идиомы.

Давайте объявим эту фичу depracated

Ты можешь называть переменные в under_score, и это будет работать и это будет "Я используя механизм резолва переменных", но это будет неидиоматично.

Не передергивай

А почему бы и нет?

Ну если у меня 3 версии lodash, то я таки напишу что-то похожее.

Всегда делал симлинк в node_modules, только вчера начал делать с NODE_PATH - и на тебе говорят будет deprecated, так это так?

Не deprecated, см выше ссылку на коммит и закрытый PR

deprecated

просто его не планируют удалять

legacy, в общем

deprecated

Пруф?

It's been semi-deprecated for ages but we have been stupid enough to leave it in the documentation without so much as a deprecation notice

Что в замен-то?

https://github.com/nodejs/node/issues/1627

Что в замен-то?

использовать относительные пути

https://github.com/nodejs/node/blob/be68b68d4863f0d389cc46fdf6f1cbcd1b241d0a/doc/tsc-meetings/io.js/2015-04-08.md

использовать относительные пути

Относительные пути отлично работают, когда мы говорим про структурную парадигму и строгую композицию. Вот только реальный мир не такой, увы. Как предлагаешь бороться с каким-нибудь ../../../../resources/offers.js?

Делать нормальную структуру папок

Относительные пути отлично работают, когда мы говорим про структурную парадигму и строгую композицию. Вот только реальный мир не такой, увы. Как предлагаешь бороться с каким-нибудь ../../../../resources/offers.js?

Если встречается нечто подобное, это, как правило, повод задуматься о структуре проекта.

https://github.com/nodejs/node/issues/146

Если встречается нечто подобное, это, как правило, повод задуматься о структуре проекта.

И как это переорганизовать? =)

С другой стороный, никто не мешает написать myRequire, который делает то, что вы хотите

И как это переорганизовать? =)

Делать все реквайры на верхнем уровне и потом прокидывать в модули ниже например, а-ля dependency injection.

С другой стороный, никто не мешает написать myRequire, который делает то, что вы хотите

И потерять поддержку IDE и прочих анализаторов?

> Paul И потерять поддержку IDE и прочих анализаторов? да

Делать все реквайры на верхнем уровне и потом прокидывать в модули ниже например, а-ля dependency injection.

ОМГ. Серьёзно?

поддержку вы потряете в любом случае

Нет, ибо NODE_PATH есть и о нём знают

Обязаны знать, во всяким случае

он есть, но он есть где и когда?

ОМГ. Серьёзно?

Это один из вариантов, и в общем случае не вижу в нем ничего криминального. Чем меньше реквайров внутри модулей, тем лучше тестируемость, опять же.

Обязаны знать, во всяким случае

А про алгоритм поиска не обязаны? Двойные стандарты какие-то

откуда ide знает, какой NODE_PATH будет при запуске проекта?

А про алгоритм поиска не обязаны? Двойные стандарты какие-то

Обязана про алгоритм поиска, я же не спорю

откуда ide знает, какой NODE_PATH будет при запуске проекта?

А откуда она знает, что при запуске .my-file будет тем же?

каким тем же?

Это один из вариантов, и в общем случае не вижу в нем ничего криминального. Чем меньше реквайров внутри модулей, тем лучше тестируемость, опять же.

Для тестирования никто не мешает подменить require.

каким тем же?

Какой при разработке, КО

Для тестирования никто не мешает подменить require.

Никто не мешает, но, имхо, всякие proxyquire - это "грязный" подход. Да, где-то без этого не обойтись, но чем такого меньше, тем лучше, как по мне.

Никто не мешает, но, имхо, всякие proxyquire - это "грязный" подход. Да, где-то без этого не обойтись, но чем такого меньше, тем лучше, как по мне.

Почему грязный?

Почему грязный?

Потому что, одно дело когда у тебя есть модуль, у которого есть четкая сигнатура api, и ты знаешь, что он принимает и возвращает, даже не залезая внутрь самого модуля. И совсем другое, если внутри модуля используются какие-то зависимости, объявленные через require.

откуда ide знает, какой NODE_PATH будет при запуске проекта?

в вебшторм для нужных директорий mark directory as -> resourse root и все хорошо, знает

Потому что, одно дело когда у тебя есть модуль, у которого есть четкая сигнатура api, и ты знаешь, что он принимает и возвращает, даже не залезая внутрь самого модуля. И совсем другое, если внутри модуля используются какие-то зависимости, объявленные через require.

ты предлагаешь отказаться от модульного подхода в пользу.. чего?

http://krasimirtsonev.com/blog/article/how-require-import-may-decrease-your-testability вот один из примеров того, о чем я говорю

И где там про замену require?

О чём ему в комментах и намекнули

ты предлагаешь отказаться от модульного подхода в пользу.. чего?

Я не предлагаю отказываться от модульного подхода. Я всего лишь говорю, что зачастую лучше, когда существует некий единый aggregation root, чем размазанные по всему проекту require, особенно "снизу вверх" по структуре (require('./../../../../offer')).

Эм. Ты подменять будешь целый модуль, после резолва, а не этот путь.

Паш, я вообще верстальщик, и ни на чем не настаиваю, к чему этот спор? :)

Ну ок.

Всем привет, кто-нибудь может подсказать хорошую библиотеку для распарса жесткой xml ?

Всем привет, кто-нибудь может подсказать хорошую библиотеку для распарса жесткой xml ?

Привет. Пробовал xml2js?

Всем привет, кто-нибудь может подсказать хорошую библиотеку для распарса жесткой xml ?

Есть четыре базовые библиотеки https://github.com/astro/node-expat https://github.com/libxmljs/libxmljs https://github.com/isaacs/sax-js https://github.com/fb55/htmlparser2 На базе них есть ряд других библиотек - но выбор нужно сделать между этими ( sax-js - чистый JS без native зависимостей ) - ( node-expat - требует node-gyp и компиляцию как и libxmljs ) ( htmlparser2 - не смотря на свое название довольно хорошо парсит xml - тоже чистый JS ) xml2js базируется на sax-js но ему я не доверяю - он на coffeescript. https://github.com/cheeriojs/cheerio ( лучшая либа на мой взгляд ) - базируется на htmlparser2 https://github.com/assistunion/xml-stream - node-expat https://github.com/jimmyburgess/xml2js - sax-js

#whois Привет! Я по происхождению разработчик, сейчас у меня своя компания/команда разработчиков сложных веб-проектов (я в основном менеджерю, но иногда и сам что-то пишу), последнее время мы делаем фронт в основном на react+redux (nodejs для серверного ренеринга), бекенд чаще php, но есть проекты и nodejs (в основном там где нужна “честная” асинхронность). Сообщество мне интересно для связи с отраслью, новостей и трендов, поиска ответов на вопросы. Я могу быть полезен прежде всего по вопросам архитектуры, отказоустойчивости и масштабирования веб-проектов в целом.

#whois Привет! Я по происхождению разработчик, сейчас у меня своя компания/команда разработчиков сложных веб-проектов (я в основном менеджерю, но иногда и сам что-то пишу), последнее время мы делаем фронт в основном на react+redux (nodejs для серверного ренеринга), бекенд чаще php, но есть проекты и nodejs (в основном там где нужна “честная” асинхронность). Сообщество мне интересно для связи с отраслью, новостей и трендов, поиска ответов на вопросы. Я могу быть полезен прежде всего по вопросам архитектуры, отказоустойчивости и масштабирования веб-проектов в целом.

Как вы обеспечиваете отказоустойчивость ваших проектов?

В зависимости от потребности :-) Типичный случай: два (или больше, в зависимости от нагрузки) разных физических сервера, на каждом подняты нужные сервисы (мы стараемся следовать микросервисной архитектуре), запросы балансируюся. Ну и конечно мониторинг этого всего, чтобы сразу узнать, когда что упало.