мається повна аналогія з семантикою файлової системи, сумісної з POSIX, в якій шляху записуються щодо виконуваного файлу.
Зрозуміло, що абсолютні ідентифікатори модулів записуються відносно кореня файлової системи.
На початку ідентифікатора модуля верхнього рівня немає ні . raquo ;, ні .. raquo ;, ні / raquo ;, це просто ім'я модуля. Такі модулі зберігаються в одному з декількох наперед каталогів, наприклад node_modules, або в каталогах, перелічених у масиві require.paths.
. 2 Локальні модулі всередині програми
Всі безліч мислимих модулів можна розбити на дві категорії: що є і не є частиною програми. Модулі, які не є частиною конкретного додатка, написані, маючи на увазі якусь узагальнену мету. Почнемо з реалізації модулів, використовуваних тільки у вашому додатку.
У типовому додатку модулі розподілені по декількох каталогах. Вони зберігаються в системі управління версіями і згодом копіюються на сервери. Ці модулі знають відносні шляхи до своїх «братам» і можуть використовувати цю інформацію, щоб посилатися один на одного, але відносним ідентифікаторам.
Щоб краще зрозуміти, як це організовано, візьмемо як приклад структуру одного з пакетів для Node, каркаса розробки веб-додатків Express. Він складається з декількох модулів, організованих у вигляді ієрархії, яку розробники Express знаходять корисною. Подібні ієрархії має сенс створювати, коли додаток досягає певного рівня складності, виправдовує його розбиття на частини, більші, ніж модуль, але менші, ніж додаток. На жаль, спеціального терміну для таких структурних компонентів в Node немає, тому доводиться вживати коряву фразу «розбивати на частини, більші, ніж модуль». Кожна така частина представляється каталогом з декількома модулями.
. 3 Комплектація додатки з зовнішніми залежностями
Для включення модулів, що знаходяться в каталозі node_modules, вживається ідентифікатор верхнього рівня:
express=require ( express );
виробляє пошук модулів у всіх каталогах node_modules, а їх існує декілька. Алгоритм починає пошук в каталозі поточного модуля, потім додає в шлях node_modules і шукає там. Якщо модуль не знайдено в каталозі node_modules, то Node переходить до батьківського каталогу і пробує ще раз - і так до тих пір, поки не дійде до кореня файлової системи.
Але що, якщо ми захочемо використовувати каркас Express у своєму додатку? Нічого складного, просто створюємо каталог node_modules всередині дерева свого додатку і встановлюємо туди Express:
Тут показано гіпотетичне додаток drawapp. Якщо каталог node_modules розташований так, як показано на малюнку, то будь-який модуль всередині drawapp може отримати доступ до express наступним чином:
express=require (express ');
Однак ті ж самі модулі не зможуть дістатися до модуля qs, прихованого всередині каталогу node_modules, що є частиною самого каркаса Express. Перегляд каталогів node_modules, що містять шуканий модуль, проводиться вгору по ієрархії файлової системи, без заходу в дочірні каталоги.
Аналогічно: якщо встановити модуль в каталог lib/node_modules, то він буде доступний з draw.js і svg.js, але недоступний через index.js. Як і раніше, пошук відбувається вгору від поточного каталогу, а не вглиб нього.
При обході каталогів node_modules Node зупиняється, як тільки знайде шуканий модуль. Так, якщо посилання зустрічається у файлі draw, js або svg.js, то будуть переглянуті наступні каталоги:
/home/david/projects/drawapp/lib/node_modules
/home/david/projects/drawapp/node_modules
/home/david/projects/node_modules
/home/david/node_modules
/home/node_modules
/node_modules
Каталог node_modules відіграє найважливішу роль, дозволяючи системі управління пакетами виплутатися з лабіринту конфліктуючих версій. Замість того щоб поміщати всі модулі в одне місце і повільно сходити з розуму, намагаючись вирішити залежно від конфліктуючих номерів версій, ми можемо завести кілька каталогів node_modules і при необхідності складати конкретні версії в конкретне місце. Різні версії одного модуля можуть перебувати в різних каталогах node_modules, і за умови, що ці каталоги розташовані правильно відносно один одного, ніяких конфліктів не виникне.
Нехай, наприклад, ми написали додаток, в якому використовується модуль forms (http://github/caolan/forms) для побудови форм, і, коли у вас вже накопичилися сотні форм, автори модуля внесли ...
