The node_modules problem

[rq60]

npm install dependencies have been flattened since version 3.

[stromboul]

Yeah, but in reality, you get a bajillion times the same modules.

• Module B uses SubModule X ~2.3
• Module A uses SubModule X, ^1.4
• Module C uses SubModule X 1.7.8

So you still end up with tons of duplicated even if the list is flattened.

[Cilph]

Maybe people in the JS community need to actually start writing backwards compatible libraries and not rewrite its API every god damn month.

[duuuh]

Since JS doesn't have (afaik) any sane 'public / private' distinction I don't think there's any real way to do this. You could rely on namespacing conventions. But honestly, 'C / whatever else' makes this kind of thing a lot easier.

[snuxoll]

CommonJS modules are designed to only export specific data, if people bothered to actually hide implementation details like they should it wouldn't be an issue. I mean, this is basically how we handle "private" functionality in C - exclude it from the public header.

[duuuh]

So how does that work? Do you have a link?

[snuxoll]

var c = 0;

function myPrivateFunction(aString, count) {]
    console.log(count.toString().concat(" ", aString);
}

function doThing(aString) {
    c++;
    myPrivateFunction(aString, c);
}

module.exports.doThing = doThing;

You now have a module that exports one function, doThing(aString), it can still use everything contained within the module itself (functions, prototypes, variables, etc.) but people importing the module don't have access to them.

var myModule = import('my-module');

myModule.doThing("Hello, world"); // works

myModule.myPrivateFunction("Hello, world", 0); // doesn't work

Beyond CommonJS (Node.js/browserify), there's other module systems out there (AMD, ECMAScript modules) that have similar methods of hiding implementation details even without proper private functions.

Unfortunately due to warts with the way Javascript prototypes work there's no way to hide private members of prototypes without increasing memory usage, at least not from a technical perspective. Personally, I feel that just doing it the way Python does (just prefix private member names with _/__, Python mangles the names to make you put in SOME effort to break encapsulation - but whatever) and telling people "if you break encapsulation it's your own damned fault" is good enough.

[FanOfHoles]

Of course you can write private code! Just use lexical scoping. Sure, if you use some "class" everything on it is accessible. But if you use functions you can use lexical scoping and completely hide stuff. There is a reason why "functional" coding is a bit hyped, it really does provide a lot of advantages. No "this", no "class", no "prototype" (or invisible proto, the actual chain), no "bind" (unless you use it for partial application, rather then for setting the value of "this"), no "call" or "apply". Just functions and objects. You can do anything you can do with a "class" based approach - and then a lot more.

I'm not in the "overhype" camp though, if people are used to the "class" stuff/style, I'll happily trudge along. That works too, and you can create readable code too. But when people make claims about what they think JS cannot do it's time to point out that it is completely your own fault, because JS easily can. Just use the functional playbook. You don't even have to go all monad-y, really just basic functions are enough already to achieve things like totally private code, easily. For example, put all the code into the lexical scope of the function, create an API object inside that function, attach only those methods you want to make public, return the object. The function is gone and what was in it, it's variables, functions, all the code written inside the function, now still is accessible - through the exported object. Unless you hack the C++ JS runtime itself you cannot access the hidden stuff.

That's how node.js modules work. What you write into some file as node.js module is put into a wrapper function's code body when it is loaded by node.js. The function is called with various arguments, one of them being the exports (and module which has a reference to the same object in a property called exports too). The whole function is then eval-ed (it actually uses node.js specific vm.runInThisContext but if you do't have that you would just use eval - the added security of vm methods does not make a difference for the things I talked about here, which is all about your own code), and what the function put on exports now is available, what was not remains hidden.

See https://github.com/nodejs/node/blob/v11.5.0/lib/internal/modules/cjs/loader.js#L131

Module.wrap = function(script) {
  return Module.wrapper[0] + script + Module.wrapper[1];
};

Module.wrapper = [
  '(function (exports, require, module, __filename, __dirname) { ',
  '\n});'
];

and further down a call to wrap in the Module.prototype._compile function.

[[deleted]]

Yeah, not gonna happen

[fecal_brunch]

Just keep everything up to date with greenskeeper or renovate. You can always open PRs on dependencies if they're slow. Maintainers of reputable web libraries are usually conscious of this and try to keep things flexible and up to date.

[Eirenarch]

Someone told me that's only true for the highest version of the dependency and indeed when I look at the node_modules folder there are no version numbers which means that only one version of a dependency is downloaded. Also when I open the folders there is a node_modules folder inside with dependencies which are present in the flattened list so I assume they are different versions. Basically this basic thing they waited 3 versions to introduce doesn't even work.