http://www.opennet.ru/opennews/art.shtml?num=45283 Компания RethinkDB сворачивают лавочку. Надеюсь проект кто-нибудь подхватит.

ты файлы по отдельности запускаешь или всегда из главного?

http://www.opennet.ru/opennews/art.shtml?num=45283 Компания RethinkDB сворачивают лавочку. Надеюсь проект кто-нибудь подхватит.

А я только думал попробовать :(

Да я вот тоже уже начал её прикручивать к пет прожекту..

Короче, это свойства INIT_CWD, PWD в объекте process.env.

чото мне кажется что ты не прав

Ну, пока их значения не меняются.

Короче, это свойства INIT_CWD, PWD в объекте process.env.

это то, откуда ты запускаешь ноду

а не корень пакета

Неа.

Специально перешёл на каталог ниже.

PWD - Print Working Directory

Ну... Да. Я так и ожидал.

Только по факту другое поведение увидел.

это не корень)

Правда запускал через npm-скрипт.

это не корень)

Но по факту он ссылается на корень npm-пакета.

он ссылается туда откуда ты запускаешь ноду

запустишь из другого места будет показывать туда

если ты запускаешь приложение через условный app.js то тебе это решит проблему

а если ты будешь включать этот пакет в другое приложение то process.env.PWD будет указывать на приложение, а не на пакет

Печаль.

Да, я уже проверил.

Так... INIT_CWD присутсвует только если я запускаю приложение через npm-скрипт.

А как получить абсолютный путь к корню npm-модуля (изнутри него)?

require.resolve уже пробовал?

Неа

Не то же.

я правда неочень понимаю что относительно чего ты разолвишь, но обычно для этого хватает методов из модуля path, либо require.resolve

а что такое корень модуля?)

Суть в том, что мне нужен надёжный способ найти корень проекта.

process.cwd?

либо можешь привязаться к файлам через __dirname или __filename

Работает только если сам проект запускается из нужного места или через npm-script. Если же он подключен как модуль, то не подходит.

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

да какой тебе файл надо получить-то?)

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

Да.

ну тогда __dirname

относительно него резолви путь до корня

самый надежный способ

ну тогда __dirname

__dirname содержит каталог текущего файла.

да. ты же знаешь где на fs у тебя модуль лежит

в чем проблема то?

Не знаю. Модуль может быть запущен кем угодно и откуда угодно.

я уже понял, что у тебя какой-то костыль

но есть еще module.parent

выдает инфу о родительском модуле из которого загрузили твой

Не подходит.

https://nodejs.org/dist/latest-v6.x/docs/api/modules.html#modules_module_parent

тебе не угодишь :)

ты четко объяснить можешь, чего хочешь?))

в целом, это стандартные способы для определения пути

может ты к задаче неправильно подходишь?

Есть файл /unknown/path/to/project/.../.../file.js. Внутри file.js нужно получить /unknown/path/to/project.

так до проекта или до модуля?

а как этот файл запускают?

До npm-пекта == до проекта.

это cli тулза?

Файл выполняется как модуль внутри проекта. Сам проект тоже выполняется как модуль в качестве npm-пакета.

Самый простой способ вижу — подниматься по файловому пути и искать package.json;

Пока что.

может тебе наоборот пробросить этот путь внутрь?

сделай в package.json скрипт для надежности, который и будешь запускать

Это костыльнее предыдущего варианта. =)

Его никто не будет запускать. Он же npm-пакет.

ERROR: S client not available

ну как я понял у тебя схема такая, ты непонятно откуда запускаешь зависимость проекта и хочешь внутри зависимости получить путь к проекту

Бинго. =)

ну так сделай промежуточный шаг с npm скриптом

а как вызывается твой модуль?

Подключается через require.

ох

он реквайрится из проекта?

function getProjectPath() { const idx = __dirname.indexOf('node_modules'); if (idx === -1) { return __dirname; } return __dirname.slice(0, idx); }

похоже, что нет )

может тебе через стектрейс ошибки находить откуда тебя вызвали?

да не, тут лучше схему упростить

он реквайрится из проекта?

Сам проект реквайрится и модуль реквайрится.

хорошо, а почему тебе module.parent не подошел?

там есть проблема с кэшем, но в целом, если это первое обращение, то путь ты получишь

хорошо, а почему тебе module.parent не подошел?

parent может быть например src/index.js. а это не корень проекта

хорошо, а почему тебе module.parent не подошел?

module.parent мне покажет, откуда меня вызвали, но это не даст гарантии, что вызывающий файл лежит в корне проекта.

так чем мое решение не подошло?)

Там вообще файлов может не быть.

так чем мое решение не подошло?)

Ну... Как вариант.

Но равный по костыльности вариант — поиск package.json, тогда уж.

package.json тебе ничего не даст)

ты сам сказал этот модуль могут подключать через другой

в package.json может не быть зависимости

а вообще в таких случаях делают .*rc файл, по которому детектят что нужно

http://stackoverflow.com/questions/10265798/determine-project-root-from-a-running-node-js-application

Оказывается, всё очень сложно. =)

круто

Короче, я воспользуюсь app-root-path, и не буду трахать мозг.

Он, вроде, не слишком толст.

Кто-то с loopback на короткой ноге? Как кастомную валидацию мутите? Попробовал поиграть с Models.validateAsync, а контекст получить не могу, чтобы провалидировать поле, как жить?

перейти на Rails?

Одна хуйня