Since it's still being discussed...
## To give some context I'm all favor of small modules that does one thing and does it well, "single responsibility" is usually my mantra except when it doesn't. Almost all my open source projects have a single responsibility: - http://millermedeiros.github.com/js-signals/ - http://millermedeiros.github.com/crossroads.js/ - https://github.com/millermedeiros/nodefy/ - https://github.com/millermedeiros/rocambole/ - https://github.com/millermedeiros/Hasher - https://github.com/millermedeiros/esformatter/ But there are exceptions to all rules... Around 1 year ago I decided to split some of my JavaScript helpers into individual files so I could load/require only the methods I needed - I do mostly front-end development so filesize/memory is a big concern - think of it as a modular version of underscore.js, it eventually became the moutjs project ( http://moutjs.com ), we currently have almost 200 individual modules/functions. Imagine if I decided to flood npm? With a single package/repository maintenance can be way easier - we all know that git submodules can be a huge PITA. You can have a single build script, scaffolding is easier, publishing updates is easier, managing packages is easier (less places to look for), running tests is easier, only a single travis-ci instance required, etc... It also helps on **discoverability** and **consistency** (you have a clear sense of what names are already used and everything follows same convention), less time spent on `npm search my-helper-method`, less time updating package.json, create a sense of "community", centralized bug tracker, same identity, centralized docs... Maybe you are working somewhere without internet connection and remember that you need some helper method that wasn't on your dependency list - damn.. If you had downloaded the kitchen sink (mout) instead of individual methods you could just "require" what you need, all the files you need are already inside the node_modules folder (including docs). ## Why "directories.lib" is such a big deal? It decouples the file location with the value that you are "requiring", if you decide to change the source folder structure you don't need to do a new major release, renaming folders/files should not be a reason for a breaking change. The `require()` syntax SHOULD be flexible, it's just a string ID used to map into some module, there is no good reason for it to not allow a different scheme than the fs. I would go even further and add an "alias" setting (similar to the old "modules"[1]) to have local remap of modules so you could `require("foo/bar")` and load "foo/ipsum" instead. This would solve issues with "long-and-bad-module-names" and would make the whole namespace discussion irrelevant. It would also reduce backwards incompatibilities just because you decided to rename an internal file. ## "Hard to debug" myth I call it BS. If `npm explore foo` and `npm edit foo` doesn't work as expected then it is an npm issue, fix/improve/adapt the tool, don't limit the package structure just because the tools aren't good enough. Each top-level package contains a package.json with ALL the config, just need to read the closest one... It's like when you create an alias to a method, it doesn't get harder to debug, it just have a different name, call stack still works the same, line numbers match, file path match. It is not a big deal if you app requires "foo" and in fact it loads "bar" it's YOUR app, just open the package.json and read what has been remapped, or add a new command to npm that displays which module is being loaded for a given ID, just like `which npm` works, problem solved. ## Namespaces are old school Saying that the user should put everything into the same "namespace" when we have a real module system is silly. `I.dont.want.to.write.code.like.this()` Also saying that every package should consist of a single script or all files should be on the root folder is naïve... "A reprogrammable system is incredibly powerful. Abusing the power is always possible and it's a point of principle in a reprogrammable system that people must be able to abuse it." - @nickferrier --- I solved this "issue" on moutjs by converting all modules to node.js format and putting the files on the root folder during "npm prepublish" so the same require paths are used on AMD and node.js, but it feels dumb to have to place everything into the root folder, also made it slightly harder to cleanup the folder after `npm publish` (more paths to `rm -r`). The system have flaws, it's not because we can be "creative" about how to solve it that the problem goes away. [1] how "modules" worked in npm a couple years ago: https://github.com/isaacs/npm/commit/a12ead34615bf62eae106010c8b27069e98e5f 63 -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
