javascript - Is it ok to rely on node.js module state? -
first of i'm not experienced in node.js. understanding of node.js' modules act pretty same python's modules. mean executing code once , maintaining internal state. until i've read this article:
but might not realize (i sure didn't!) if project based on npm modules both require "shared" module dependency, this:
node_modules/one/index.js: var shared = require('shared'); node_modules/two/index.js: var shared = require('shared');
... , install dependencies npm, there 2 copies of "shared/index.js" hanging about:
node_modules/one/node_modules/shared/index.js node_modules/two/node_modules/shared/index.js
after reading i'm not sure, 1 can rely upon module's internal state because of possibility of existence of 1 module on different paths , hence having 2 or more instances of same module in cache. means @ least "no more singletons through native modules mechanism". meanwhile, haven't heard such problem in python.
does mean modules have return functions/constructors (like express.js
app creation flow) , avoid internal state?
internal state on node modules differs when modules loaded different paths, sort of depends on version of npm you're using , how dependencies managed.
this more of npm question since you're using manage dependencies.
npm 2 has more nested approach installing dependencies means you'll have lot more copies of single module if install using npm 3.
example. lets install module , module b both depend on version 1.4 of module c, npm 2 get:
+- module | | | + module c v 1.4 | +- module b | + module c v 1.4
which means modules , b have entirely different versions of module c loaded.
if run npm dedupe
, should idealize tree be:
+- module | +- module c v 1.4 | +- module b
this flatter tree npm 3 attempts create.
having worked on systems trying rely on inherent single-instance of shared module being present, recommend trying not that. npm 2 dedupe
has fair share of issues, , npm 3 still has performance issues it.
Comments
Post a Comment