Isaac, I know your position on npm and similar arguments have indeed
come up in the past and you have responded in a similar manner. I was
only asking if someone has a solution today because I can't follow
everything that is going on. I didn't even knew about the gh user/repo
thing, which is solving my primary problem and npm doesn't need to
change at all and it can be single namespace or however you like, it's
your project and most people seem to be ok with it and I don't want to
argue about that.
Npm can be what it is and that is absolutely fine.
But, since *some* people do want to use gh paths I think it's improper
to tell us all that we're wrong and that this is life and we should
live with it or keep our projects in our closets because we don't like
obscure naming. I'm only asking that you consider the possibility that
we extend search and only search to include these projects as well,
since they *do* exist and people *are* making such projects. I
honestly believe that they can co-exist and the world is not going to
collapse by this subtle addition.
On Sunday, May 26, 2013 7:14:29 PM UTC+3, Isaac Schlueter wrote:
>
> 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
> <[email protected]<javascript:>>
> wrote:
> > 2013/5/26 Eldar <[email protected] <javascript:>>:
> >> 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 [email protected]<javascript:>
> >> To unsubscribe from this group, send email to
> >> [email protected] <javascript:>
> >> 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 [email protected] <javascript:>.
> >> 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 [email protected]<javascript:>
> > To unsubscribe from this group, send email to
> > [email protected] <javascript:>
> > 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 [email protected] <javascript:>.
> > 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 [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
---
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
