это фишки для фронт енд хипстоты

https://gist.github.com/branneman/8048520 все варики, но меня ни один не прельщает. кроме наверное globals

это фишки для фронт енд хипстоты

Да, там нет ни того, ни другого

Бывают ситуации, когда в приложении есть модули-хелперы этого приложения и лежат рядом с ним и в глобале никому не сдались. Делать для них отдельную репу (и тем более заливать в npm), версионирование, кажется лишними хлопотами. Пока лучшего решения для такого кода я не вижу, хоть оно и имеет свои недостатки.

Зато не подгорает при очередном require, когда надо понять где лежит модуль относительно файла. Полагаться на proccess.pwd тоже нельзя.

или в node_modules класть, но у коллег от этого бомбит

и еще как

А лучше выкинуть require

и еще как

даа бро, я чувствую твою боль

Вообще если весь код в отдельной папке, то в неё можно положить node_modules

я про это и говорю

модули, которые ты запрашиваешь через ../../

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

а чем с NODE_PATH плохо?

Deprecated

Deprecated

Пруф?

Пруф?

Уже как несколько лет

Deprecated

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

Уже как несколько лет

C require.path не путаешь?

C require.path не путаешь?

Вот тоже подумал

Как раз на NODE_PATH перешли

Ну, что ../../../.. не вариант, это однозначно

Никто не запрещает использовать 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

ERROR: S client not available

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

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

С другой стороный, никто не мешает написать 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?