Можно ли полагаться на состояние узла node.js?

Question

Прежде всего, я не настолько опытен в Node.js. Мое понимание модулей Node.js заключалось в том, что они действуют так же, как и модули Python. Я имею в виду выполнение кода только один раз и сохранение внутреннего состояния. Пока я не прочитал this article:

Но вы не могли бы понять (я уверен, что не сделал!), Что, если ваш проект на основе НПХ модулей, которые оба требуют «общего» модуля как зависимости, как это:

node_modules/one/index.js: 
var shared = require('shared');  

node_modules/two/index.js: 
var shared = require('shared'); 

... И установить их зависимости НПМ, будет две копии "общих/index.js" болтался:

node_modules/one/node_modules/shared/index.js 
node_modules/two/node_modules/shared/index.js 

После прочтения я не уверен, что можно полагаться на внутреннее состояние модуля из-за возможности существования одного модуля на разных путях и, следовательно, иметь два или более экземпляров одного и того же модуля в кеше. Это означает, что, по крайней мере, «Больше не существует синглетов с помощью встроенного механизма модулей». Между тем, я не слышал о такой проблеме в Python.

Означает ли это, что почти все модули должны возвращать только функции/конструкторы (например, поток создания приложений express.js) и избежать внутреннего состояния?

Answer 1

Внутреннее состояние модулей узлов отличается только тогда, когда эти модули загружаются из разных путей, поэтому зависит от того, какую версию NPM вы используете и как управляются зависимости.

Это действительно вопрос NPM, поскольку вы, вероятно, используете это для управления вашими зависимостями.

НАЯ 2 имеют более вложенный подход к установке зависимостей, что означает, что вам понравится иметь гораздо больше копий одного модуля, чем если бы вы установить с помощью NPM 3.

Примера. Допустим, вы устанавливаете модуль A и B Модуль которые оба зависят от версии 1.4 модуля С, с НПМ 2 вы получаете:

+- Module A 
| | 
| + Module C v 1.4 
| 
+- Module B 
    | 
    + Module C v 1.4 

Что означает модули А и В будут иметь совершенно различные версии модуля C загружены.

Если вы запустите npm dedupe, он должен идеализировать это дерево, чтобы быть:

+- Module A 
| 
+- Module C v 1.4 
| 
+- Module B 

Это пологое дерево также то, что НПЕ 3 попытки создать.

Работая над системами, в которых мы пытались полагаться на присущий единый экземпляр совместно используемого модуля, я бы рекомендовал попробовать НЕ сделать это. NPM 2 dedupe имеет свою долю проблем, а у NPM 3 все еще есть проблемы с производительностью.