On Sun, Jan 20, 2013 at 1:36 AM, Austin William Wright
<diamondma...@users.sourceforge.net> wrote:
> You cannot make the assumption that that's the one correct way to do things.
> Even if you can't think of a reason that someone would want to stuff their
> files in a subdirectory, that's no reason at all to not allow it.
Node and npm do not disallow subdirectories. You can use as many
subdirectories as you like. But if you want to do
`require('foo/bar.js')` then 'bar.js' has to be in the root of the
'foo' package. You can put files in the root of the package, if
that's what you want.
All that Jake said was "If there are too many files, then don't have
so many files", which is basically the most simple solution that can
be devised.
On Fri, Jan 18, 2013 at 9:36 PM, Miller Medeiros
<lis...@millermedeiros.com> wrote:
> EVERYONE knows that you can use the full path or put the files at
> the root folder - both are far from being "optimal" as described on
> previous emails.
Correct. "Optimal" is exporting a single thing, which does one thing well.
The ugliness of the long paths and cluttered folders is merely a
reflection of the ugliness of an inelegant design. Node will not
prevent you from doing ugly things, but neither will it paper over
their ugliness. I know that sometimes ugly things have to be done,
and sometimes de-uglifying is not worth the effort. (Take a look at
npm's source some time.)
> It's not because you can do some silly hack that the
> problem doesn't exist, common patterns are usually a "sign" of "flaws" on
> the system itself.
I agree, but in this case, the flaw is in the bag-o-tricks module.
Carve your solution at the joints, and write small modules which do
one thing well, and can be easily assembled. They're easier to test,
easier to document, easier to understand, easier to use (in isolation,
or together, or with other different modules), and easier to fix (or
rewrite) when they're found lacking.
> Node.js is popular and because of that it has the power to "dictate" its
> own way and flexible systems will have to "bend" to fit the dull model.
We like dull models. They're easier to reason about. Programs should
be boring dull things that solve problems in predictable ways.
> "Write once, run everywhere" won't happen anytime soon because some people
> insist to not follow the specs[2]. - that's exactly what made client-side
> development a chaos, don't commit the same mistake.
You say "some people insist to not follow the specs" as if that spec
has EVER mattered. Writing up a bit of documentation on a wiki page
and then calling it a "spec" doesn't confer magical powers.
The documentation for the properties that matter in package.json files
is here: https://npmjs.org/doc/json.html (or `npm help json`). That's
authoritative. If you find any way in which node or npm deviate from
the contents of `npm help json`, then it's a bug.
Specs are a thing of the past. Node is the spec. Node is server-side
JS. This has always been about having a single-minded laser-like
focus on making Node better, regardless of what any other system does
or any other doc says. We will take good ideas from them, if those
ideas make sense for us, but if those ideas don't make sense for Node,
we are happy to ignore them.
Someone with the ability to do so should edit
http://wiki.commonjs.org/wiki/Packages/1.1 to mention that it does not
apply to node, never has, and never will. It's only a confusing
distraction.
> I won't push this any further, maybe one day you guys will realize that in
> some specific cases this actually makes sense. I should not be spending my
> whole day adding more dependencies to my package.json or handling multiple
> separate repositories when keeping everything into a single project would
> be way easier to maintain. Don't hurt my productivity just because it goes
> against your personal preferences, think about the users and what they are
> trying to achieve, don't be a wall in the middle of the way.
Who's a wall? You can either put your files in the root of your
package, or you can put "lib/" or whatever in your require() function
calls. You're saying that you want to add complexity to Node that *no
one else wants*, because you don't want to have to choose between a
bunch of files in the root of your project or an extra *4 characters*
in your require() statements.
How much does this really hamper your productivity? With the
keystrokes spent on this email, you could have typed out "lib/" in
thousands of require() statements already.
What is this really about? Is it just a reaction to the attitude that
Node is better than anything else? Does it seem cocky or arrogant to
reject features simply because they are not something we care about?
What kind of project maintainer would I be if I cared more about silly
things like this than actual real problems that need fixing?
--
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
