This has come up before, plenty of times.  npm has a single layer
namespace, and this is intentional.  The reason is so that different
things have different names.

What would you think if I had a module in github called "request",
which was *not* related to Mikeal's "request" module?  I can do this
today with github, and there are some cases with github where this may
be sensible.  Maybe my thing is a Ruby program, that has nothing to do
with Node.  The context of github is vast, because it covers all of
OSS.

But, if I wrote a JavaScript program called "request", that runs on
Node, and isn't a fork of mikeal/request, well, I'm basically just
being an asshole.  If you read my code and see require('request') and
then it's something *other* than making http requests in the way that
mikeal/request works, then it's super confusing.

The human brain only has a single layer namespace per context.  Node
and npm create a single context.  The reason why it doesn't make it
easy for you to have multiple different things with the same name is
that *that's a terrible idea*.  It optimizes "pretty code for me" over
"understandable code for the community", and that's just the wrong
design goal.

If you really must have this, fine.  Bundle your dependencies, and
then they're your problem, not npm's, and you don't have to worry at
all about where they came from or what they're called.  Or have your
dependency be met by a github url.

It's going to mess up the npm metadata somewhat, because we assume
that names have meanings.  So, the fact that almost no one does this
is actually quite convenient.  For thousands of module authors, this
isn't a shortcoming or a bug, it's a very nice simplifying feature.

Of course, if you have a thing that you think ought to be called
"merge" *instead*, and you would like to take over the "merge" name,
ask the author nicely.  See http://npm.im/doc/disputes.html

If you would like to have your thing be named "merge", and it's not
related to another thing that is also named "merge", then there's
really no way to "have discoverability" without also causing a lot of
confusion for users.  When I read some code, and see
"require('merge')" how am I to know what that means?

If you think that there's "no good names in npm", then you probably
have one or more of these three problems:

1. You're solving a problem which is already solved (perhaps by the
OTHER "merge" module)
2. You're solving an ill-defined problem (which is why it's hard to
come up with any better name in the first place)
3. The name you've chosen is not actually the best name for what
you're trying to do.



On Sun, May 26, 2013 at 2:03 AM, George Stagas <gsta...@gmail.com> wrote:
> 2013/5/26 Eldar <eldar...@gmail.com>:
>> I migrated to components for both client and server side, though my
>> motivation is different:
>>
>
> I don't want this thread to turn into npm vs component design, just
> fix discoverability for those who prefer gh paths is sufficient.
>
>> 1) node_modules is a weak structuring pattern
>>
>> The most common approach for applications is to have a bunch of local
>> modules without package.jsons and a huge root
>> package.json with all external dependencies listed here. But it's obviously
>> better to have even local modules to be completely specified and
>> independent.
>> Though you can do that there are still rough unrounded corners. For example
>> it's hard to use two versions of the same lib in one app (say slow migration
>> to a newer version with API changes). There are other unfortunate points -
>> runtime overhead, specification of dependencies is not forced, etc.
>>
>> 2) component.json is just better
>>
>> What I mostly like about component.json is that it requires explicit listing
>> of all assets. I found my .scripts array to be constantly simpler,
>> containing fewer entries than a properly configured .npmignore (which is
>> overhead and complexity by itself)
>>
>> 3) components are better for browser and other environments
>>
>> As a consequence of better design component system is much easier to
>> implement and use for browser, chrome apps and any other environment. With
>> time the difference between them becomes more and more obscure. For example
>> many node specific objects and modules like Buffer, fs, etc are already
>> available on browser. We already have a lot of code making sense for both
>> client and server with time everything will work everywhere. That means we
>> need a common package format for the whole web. Component is a better
>> candidate for such.
>>
>> 4) npm register is hard to setup
>>
>>
>> On Saturday, May 25, 2013 10:49:09 AM UTC+4, stagas wrote:
>>>
>>> Hi all,
>>>
>>> I really want to name my modules however I like and be installable and
>>> require-able.
>>>
>>> For example, I want to write a 'merge' utility, and I don't want to
>>> struggle coming up with a random set of letters because I want my code
>>> to read require('merge') not require('golalamergifiable').
>>>
>>> What are my options currently? Anyone have any solutions?
>>
>> --
>> --
>> 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
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to