I'm also getting confused, but still I'm after simplicity and rather happy that 'directories' are not supported any more.
Isaac do you see any semantics in 'lib' folder? Do you feel that some modules should rather be placed in 'lib' than at 'root' fo the package (or other way) or it's totally "whatever works" in your opinion? I always have problem with that, firstly lib makes my root clean, but on contrary it makes require import verbose and not that clean. Additionally I don't agree with suggestion to put all package code into one big module. Smaller modules are much more maintainable and provide better customizability for users of the package, it's especially important if you port your modules for the browser. On Thursday, January 24, 2013 6:47:06 AM UTC+1, Miller Medeiros wrote: > > 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
