My 2 cents on modules

[leo]

First off: I'm relatively new to node (started developing with it a few months ago). I'm not yet one of those experienced professionals in this area, so please don't take my arguments to seriously. I'm just trying to describe what bugs me about the way, how modules in node currently work.

I started developing a secret project a while ago and I've immediately figured out that this is one of the major things which prevents me from bringing some logic in the structure of the project. And that's exactly why I'm here now and want to talk about this.

When talking about open source projects, I'm usually very concerned about doing stuff the way how it was intended by it's creators (since that mostly leads to clean code and a faster development process). I'm also very happy about the fact that there are many people out there who are contributing to the openness and trying to make the standards easy to understand, so that new users like me can quickly get started without needing to think about their own structure.

Anyway. Let's talk about the problem: To me, it feels like the logic behind the way how modules are intended to be structured within apps, isn't that awesome. When installing a module (or "package", if you want), the developer usually has the choice between installing it within the app's directory (then it will be put in the "node_modules" folder) or setting it up globally using the -g parameter when installing.

Problems and their solution

Why don't we just install all modules globally by default? And if a module needs to require it, it will simply be loaded from that global directory where all modules live. Some advantages this method will entail:

1. No more duplicated modules: Every time you set up an app that has some other modules as dependencies, those might also have modules as dependencies which the app itself already requires. Also: One of the most important coding-mantras is "Don't repeat yourself!". It doesn't matter how many different node apps are operating on a machine, they could simply all access one single module rather than installing it again & again & again.
2. Goodbye, nesting inception: Okay, let's assume we want to write an app with node. Since it's an environment that comes with very less functionality by default, we usually need a few modules to achieve what we want. — So let's install the first module... Ahh, cool! Looks like it also has some dependencies itself and nice, it even installs them automatically... Great, then let's have a look into the folder: Okay, those dependency modules of the module we've installed also have some other modules which they depend on, hmm. Oh, looks like the depending modules of the modules on which some of our depending modules depend on, also have some dependencies. Great! — But we could avoid this whole mess by putting all those modules on the same level, so that we have a great overview rather than a folder in a folder in a folder in a folder.
3. Alway up-to-date: If some of our apps only need 1.3.0 of a specific module, they will now also get a higher version if a different app on the system depends on it (if another module depends on 1.5.0 of the said module, for example - the above app will also get this version, since the only instance of this module will of course be updated to fit the highest dependency). — I hope that's understandable.
4. Faster, more secure and easier on large deployments: If there's a machine with multiple apps on it, there won't be hundreds of thousands instances of the same module which need to be updated to a specific version. There's only one instance of this module on the system: The latest. And if you're now thinking: "What if an app needs an older version of an module?" — If that's a big point for you, what about creating a single, global folder for this module which contains multiple versions: 1.0.0, 1.0.1 and 1.0.2 for example, etc. — Because if you ask me, latest should always be the default, there shouldn't be an excuse. But if it's really necessary, than the app could also require it.

More specific: If a module depends on other modules, NPM will still install those automatically if they're listed within the package.json file - just globally (by default), rather than locally.

---

I'm not sure but I think we also wouldn't be the first ones implementing this method. Just think about how Ruby does it with Gems. They're all in one place. No nesting, no confusion.

So what do you think about this? Aren't you also tired of this never ending story of modules that are nested to the moon?

[kenany]

Relevant:

• "Why can't npm just put everything in one place, like other package managers?"
• "Whatever, I really want the old style 'everything global' style."

[leo]

I guess the biggest problem here is that many of us are afraid of introducing this method, since it will break compatibility if a module needs an older version of another module. And I know that this is really important for you.

But why don't we just make "latest" the default when requiring? And if a module needs a specific older version of another module, it needs to specify the version tag when requiring it within the code.

[jasnell]

Definitely appreciate the discussion, but this kind of discussion is better directed at either the https://github.com/nodejs/io.js next branch or even npm.

[Fishrock123]

Actually, it'd be best to discuss this in N(ext) G(en): https://github.com/nodejs/NG than io.js, but it's probably also a topic for npm, however the npm issue tracker is lready busy enough as it is, so I suggest NG.

bottom line: we can't just change modules, but maybe in some future.