Module naming

[George Stagas]

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?

[Alex Kocharin]

RPG name generator could do the job. :)

--
// alex

25.05.2013, 10:49, "George Stagas" <gst...@gmail.com>:

> --
> --
> 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 nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@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+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Göktuğ Kayaalp]

With project-local node_modules directories, this kind of name
collisions should not be an issue.

--
Göktuğ Kayaalp <goktug....@gmail.com>

[George Stagas]

2013/5/25 Jonathan Ong <jonathanr...@gmail.com>:
> just don't bother publishing it. use github namespaces in npm.
>
> {
> "dependencies": {
> "merge": "stagas/merge"
> }
> }
>

It seems to work, but then, there's the issue of discoverability. It's
a double edged sword now, either obscure naming and npm indexing or
proper names and invisible.
Why is life so tough.

[Alex Kocharin]

It's an answer to unrelated question. If a package is intended to be used in public, it should be in public registry (npmjs.org). If it's for internal use, github will do fine.

But namespaces could do the job if you publish a package with a name like "stagas.merge". It's quite uncommon though.

On Saturday, May 25, 2013 1:39:19 PM UTC+4, Jonathan Ong wrote:

just don't bother publishing it. use github namespaces in npm.

{

  "dependencies": {
    "merge": "stagas/merge"

  }

}

On Saturday, May 25, 2013 1:34:51 AM UTC-7, Alex Kocharin wrote:

[George Stagas]

2013/5/25 Alex Kocharin <al...@equenext.com>:

>
> It's an answer to unrelated question. If a package is intended to be used in
> public, it should be in public registry (npmjs.org). If it's for internal
> use, github will do fine.
>
> But namespaces could do the job if you publish a package with a name like
> "stagas.merge". It's quite uncommon though.
>

I want both visibility and proper naming. That logic isn't valid.
Github is very public. We just need to find a way to index these along
with the rest npm modules. Whoever likes can publish to npm, whoever
likes can push to Github. Both should be given equal chance of
discovery though.

[Alex Kocharin]

> Whoever likes can publish to npm, whoever likes can push to Github. Both should be given equal chance of discovery though.

Github is a tool for development, npm registry is a tool for deployment. Am I missing something here? By the way, mix of those two is very well known to create serious trouble (https://github.com/isaacs/npm/issues/1727).

Also, there was a holywar in npm issues about namespacing... I guess anything about "proper naming" has been said there already:
https://github.com/isaacs/npm/issues/798

[George Stagas]

2013/5/25 Alex Kocharin <al...@equenext.com>:

>
>> Whoever likes can publish to npm, whoever likes can push to Github. Both
>> should be given equal chance of discovery though.
>
> Github is a tool for development, npm registry is a tool for deployment. Am
> I missing something here? By the way, mix of those two is very well known to
> create serious trouble (https://github.com/isaacs/npm/issues/1727).
>
> Also, there was a holywar in npm issues about namespacing... I guess
> anything about "proper naming" has been said there already:
> https://github.com/isaacs/npm/issues/798
>

They're both public data containers that you upload stuff into. One
has a single namespace, the other has a username-based namespace.
What's for "deployment" and what's for "development" are purely
personal choices.

[Marco Rogers]

It's not clear from this thread what you want exactly. You want to name your modules whatever you want, not use namespaces, have them on npm, and also avoid name collision? How exactly do you see that working?

:Marco

[George Stagas]

2013/5/26 Marco Rogers <marco....@gmail.com>:

> It's not clear from this thread what you want exactly. You want to name your
> modules whatever you want, not use namespaces, have them on npm, and also
> avoid name collision? How exactly do you see that working?
>
> :Marco
>

I'm sorry, we lost it somewhere in the middle. I just want my code to
read properly like var merge = require('merge'); not 'stagas-merge'
and this issue is solved by npm as Göktuğ pointed out but now my other
issue that came up is that by not publishing to npm and using github
paths it kills discoverability. So I think, so that everyone is happy,
we need to find a way to index these along with the regular node
modules search, which is unfortunately tied to npm atm.

[George Stagas]

2013/5/26 George Stagas <gst...@gmail.com>:

> 2013/5/26 Marco Rogers <marco....@gmail.com>:
>> It's not clear from this thread what you want exactly. You want to name your
>> modules whatever you want, not use namespaces, have them on npm, and also
>> avoid name collision? How exactly do you see that working?
>>
>> :Marco
>>
>
> I'm sorry, we lost it somewhere in the middle. I just want my code to
> read properly like var merge = require('merge'); not 'stagas-merge'
> and this issue is solved by npm as Göktuğ pointed out but now my other
> issue that came up is that by not publishing to npm and using github
> paths it kills discoverability. So I think, so that everyone is happy,
> we need to find a way to index these along with the regular node
> modules search, which is unfortunately tied to npm atm.
>

A hackish solution that pops in my mind is to have a dummy module
'stagas-merge' that requires the gh stagas/merge and reexports it, so
that I can publish it and be indexed, but that's not ideal.

[Eldar]

I migrated to components for both client and server side, though my motivation is different:

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

[George Stagas]

2013/5/26 Eldar <elda...@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.

[Isaac Schlueter]

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.

[Alex Kocharin]

On Sunday, May 26, 2013 8:14:29 PM UTC+4, Isaac Schlueter wrote:

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.

Context of npm registry... is it "registry" or "repository"?.. could be just as vast. I mean, one module might be called "merge" because it merges objects, another module might be called "merge" because it merges modules, third one might merge universes together and still be in npm registry because it's written in js... 

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

How many disputes do you receive per month? Is there a mailing list or something where I can see ownership changes and reasons for such changes?


--
// alex

[stagas]

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.

[stagas]

As I see it, npm is 3 things right now:

1. a registry (single namespace by design, never going to change, fine)
2. a package manager (works with npm registry and recently gh user/repo, great!)
3. a module discovery platform (but sadly, only for the npm registry)

Let's just fix #3 to include user/repo projects. That is all it needs to be full and complete. Otherwise me and other people will continue to bug you until the end of time :) this issue isn't going to go away, it's only going to get worse as more people make more modules IMHO.

Also, I was looking at the Most starred in npmjs.org website. Here they are:

136 express
62 request
60 async
50 socket.io
49 mocha
45 grunt
41 underscore
36 jade
34 redis
33 connect

From these 10 modules, 4 have proper naming that kinda describe what they're about (request, async, socket.io and redis). 1 is kinda misleading (connect), and the rest have fancy names because it's just not creative to name a web framework 'server' or a test framework 'test' or a template library 'template'. They need to stand out because of their nature and be memorable. But common tasks favor first-comers because it's the thing that people will type when searching for something and it will come up at the top. If I want to make an http request module I don't see the problem naming it 'request' as well since that's what it does.

Not all cases are the same and for some projects fancy names are o.k. and for some other projects (usually single function ones) you just want them to communicate their purpose so that the code is less obscure. You say you'll be frustrated if you see require('request') and it isn't 'mikeal/request' but I'm equally frustrated when I read 'chaos' 'maga' 'jjw' 'slag' and have to dig in npmjs.org to find out what each one does.

[Dick Hardt]

I can't imagine it being a great experience to discover a package with npm that I cannot install with npm -- I would find it frustrating -- here is a package that might be useful to you, but you have to install out of band.

--

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
-- Dick

[George Stagas]

2013/5/26 Dick Hardt <dick....@gmail.com>:

> I can't imagine it being a great experience to discover a package with npm
> that I cannot install with npm -- I would find it frustrating -- here is a
> package that might be useful to you, but you have to install out of band.
>

npm can install user/repo so it might as well display them when
searching, did you read the thread or what.

[Dick Hardt]

I did read the thread

I forgot that npm can install direcly from a repo ... I never do that.

While the single name space of the npm repo does create a scarce resource, I think that a prefix or suffix on a module with a general name is ok.

ver merge = require('foo-merge') 

makes it clear which merge module you are using in your code and allows the code to be readable 

 

[Alex Kocharin]

On Sunday, May 26, 2013 10:29:07 PM UTC+4, stagas wrote:

As I see it, npm is 3 things right now:

1. a registry (single namespace by design, never going to change, fine)
2. a package manager (works with npm registry and recently gh user/repo, great!)
3. a module discovery platform (but sadly, only for the npm registry)

1. This is the registry: https://github.com/isaacs/npmjs.org
2. This is the package manager: https://github.com/isaacs/npm
3. ... well... sorry, but there is no such thing called "module discovery platform"

What do you mean by #3 here?


--
// alex

[George Stagas]

2013/5/26 Alex Kocharin <al...@equenext.com>:

command line `npm search merge` and http://npmjs.org/search?q=merge

>
> --
> // alex

[Michael Schoonmaker]

'Evening,

Greetings from a member of the (apparently) quiter majority. The way npm works today is sufficient. It solves my problems with a simplicity like no other package manager or package registry I've experienced. It's obvious and easily teachable, and is the #1 reason I ever recommend Node to anyone. Isaac is not being dogmatic here, he's being pragmatic, and there are a lot of people who agree with him.

IMNSHO, nothing about the namespacing of npm should change. Your problems should not become everyone's problems. Thank you.

[George Stagas]

2013/5/27 Michael Schoonmaker <michael.r....@gmail.com>:

> 'Evening,
> Greetings from a member of the (apparently) quiter majority. The way npm
> works today is sufficient. It solves my problems with a simplicity like no
> other package manager or package registry I've experienced. It's obvious and
> easily teachable, and is the #1 reason I ever recommend Node to anyone.
> Isaac is not being dogmatic here, he's being pragmatic, and there are a lot
> of people who agree with him.
>
> IMNSHO, nothing about the namespacing of npm should change. Your problems
> should not become everyone's problems. Thank you.
>

Good to know about your thoroughly explained arguments but nobody's
suggesting npm or the npm registry namespacing to change. Learn to
read.

[Ryan Schmidt]

On May 27, 2013, at 03:27, George Stagas wrote:

> Good to know about your thoroughly explained arguments but nobody's
> suggesting npm or the npm registry namespacing to change. Learn to
> read.

My enjoyment in reading the discussions in this group is increased when the conversation remains polite, so I'd like to advocate for that.

[Isaac Schlueter]

> How many disputes do you receive per month?

Usually less than 2 per month. But I have no way of knowing how often
authors talk amongst themselves if they already have some sort of
relationship.

> Is there a mailing list or something where I can see ownership changes and reasons for such changes?

No. The ownership of an author's modules is their own business. I
only get involved when absolutely necessary.

> 3. a module discovery platform (but sadly, only for the npm registry)

> Let's just fix #3 to include user/repo projects.

Sorry, George, that's exactly what I'm saying I *won't* do, ever. The
word "just" there is particularly odd, as if doing so would not
involve a significant amount of work, or have a significant amount of
side-effects. On the contrary, it would be a tremendous amount of
work with wide-ranging side effects. It's never going to happen.
You're asking for confusion, and I won't do it.

> You say you'll be frustrated if you see require('request') and it isn't 'mikeal/request' but I'm equally frustrated when I read 'chaos' 'maga' 'jjw' 'slag' and have to dig in npmjs.org to find out what each one does.

So, then just don't use modules that have stupid names. How is
"merge" any less vague than "chaos"? What is it merging? Is it for
doing three-way merges a la git, or merging JS objects, or applying
patch files, or merging edits from multiple sources using functional
transforms? I have no way of knowing from that name.

Be as descriptive as you need to, using as many words as necessary,
until the name is unique. You can always do `var merge =
require('object-deep-merge')` or `var merge = require('string-merge')`
or `var merge = require('git-style-three-way-merge')` or `var merge =
require('merge-patch-file')` or `var merge =
require('merge-functional-transforms')`. Better discoverability,
better readability, better debuggability.

I believe that this technique will work for the next several hundred
million modules, at least. There's a lot of english words, and the
upper limit on folder name length is very high on most operating
systems. (On windows, it gets hairy, but Node uses UNC paths by
default, so it's 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 not telling you that you're improper for using github paths, or
that you have to keep your project in your closet.

I'm saying that the npm search is not going to index anything that
isn't published to npm. I believe that this is a reasonable
constraint. Want to be in npm search? Pick a name that isn't taken,
and publish to it. Pretty reasonable trade-off, I think.

I'm also telling you that calling different things by the same name is
a recipe for unnecessary complexity.

I'm *not* suggesting that you use "obscure" names! That's terrible!
I'm suggesting that you use *more* descriptive names, which are unique
in the Node community, and that you publish them to npm, because that
is the most easy way to share code with the Node community, and
because discoverability comes with that for free.

If, for some reason, you'd like to pull your code from github instead
(or any git repo, in fact), then Good News! npm can do that. I often
point a dependency to a fork of my own while waiting for the author to
take a patch and publish to npm. But what I don't do is have multiple
different things with the same vague short name, and I certainly am
not going to encourage that by having different things with the same
name showing up in search results on the npm website.

Bottom line: I'm not telling you what to do. *You* can do whatever
you want. I'm telling you what I'm going to do, and not going to do.
It's really not negotiable, I'm sorry.

If you want discoverability via npm, then publish to the npm registry,
with all the constraints that that entails. That's all there is to
it.

[Baz]

[George Stagas]

2013/5/28 Isaac Schlueter <i...@izs.me>:

That is awesome and understood, thanks for the descriptive answer. I
was thinking more of an ad-hoc solution that doesn't mess with npm
metadata or the registry, but that is fine, I'll find a way around
this, maybe dual packaging with a long name for npm that depends on
the smaller gh path, or writing an indexing service :)

Btw, all the drama in this thread could have been avoided, I never
expected this kind of reactions for expressing my apparently unique
thoughts to the world. I will think 1000 times before posting anything
now and I believe others will suffer the same. Thanks to everyone who
contributes to that.

[Marco Rogers]

At the risk of making things worse, I don't think this is that bad George. I think the responses you've gotten here have been pretty much in line with what you asked. You got a little negativity, but not a lot. And it was good for you to expand on your ideas because your initial message didn't really convey the right things. This conversation was helpful for me, and I'm sure a few other people, in thinking about what we could do to move the ecosystem forward. Lots of people are aware that discoverability sucks and that git integration is becoming pretty important for lots of people.

I wish Isaac wouldn't be so quick to drop hammers on people's discussions by holding forth on what node/npm is or isn't going to do. (I've talked to him about it, but he's pretty stubborn). I can also see a world where npmjs.org supported searching a more expanded set of modules. It wouldn't be that difficult to visually differentiate between modules in the registry and those located somewhere else. And I actually think it might have some positive impact in that people would be more aware that they don't have to depend on what's in the npm registry. It's just one source of modules for the node ecosystem and there can be others. This is kind of orthogonal to the naming argument though. I tend to agree with Isaac there. You should name your modules uniquely. And if that's the only thing that's keeping you from publishing to the registry, that's a red herring.

Unfortunately, Isaac has different ideas about what he wants to do with npmjs.org. And since he is the node police, that means if we want something, we'll have to either convince him otherwise, or build it outside of what he's doing. Many people might not know, but they are working on enhancements to npmjs.org that help with discoverability. If we had more info about what that looked like, it might give us some ideas. Or people can decide to build their own thing. Essentially what I'm hearing is you want an extended search index that includes npm registry modules and github repos that represent node modules. We'd need to be able to tell the different between the 2, and have a way to explicitly publish github repos to this system. As Isaac said, this isn't a trivial undertaking. And people should keep this in mind when they casually ask for the core team to take on doing something like this. But it's doable if people really want it and are willing to put in some work. You are not bound by what the npm core team decides to support.

:Marco

You received this message because you are subscribed to a topic in the Google Groups "nodejs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nodejs/mhRUeX8EX2g/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to nodejs+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Marco Rogers
marco....@gmail.com | https://twitter.com/polotek

Life is ten percent what happens to you and ninety percent how you respond to it.
- Lou Holtz

[Michael Schoonmaker]

I apologize for adding to the "drama", but after reading your comments I still legitimately believed that what you were arguing towards was muddying the water between single namespace npm and dual namespace GitHub (whether through the discovery and search system or the storage is less consequential to me). I think a non-npm tool like http://eirikb.github.io/nipster/ would be the most appropriate location, and there's a lot of precedent for these sorts of tools.

-Schoon

P.S. In my case, what produced my answer wasn't the idea, but the expectations of the existing community and the core team. I'm sure I was just reading into things, but I want it to be clearer that I don't think people should keep from sharing these kinds of ideas, albeit with a different set of expectations.

[George Stagas]

Thanks guys, I think the point has been made and I appreciate your
last comments. I think I reacted a bit aggressively at some points and
sounded trollish now that I read back so your responses might have not
been entirely without basis so I apologize as well. My faith in
humanity is restored.

Have a nice afternoon.

2013/5/28 Michael Schoonmaker <michael.r....@gmail.com>:

[Mikeal Rogers]

In the earlier days of node, when isaac and i were first putting up the registry, we did think about the problems that come with a single global namespace. In the end it was still a better decision to go with a single global namespace for the following reasons.

1. Manufactured Scarcity. The "land grab" that comes with a global namespace may have issues down the line but in the earliest days of the ecosystem is a great incentive to get people publishing modules.

2. Discoverability. We may have *new* discoverability problems today but in the earliest days having one thing be one name is actually a big help for discoverability. Compare this with the early leveldb bindings mess, where Tim Caswell had one thing published, which wasn't the best/latest, that was in someone's fork, and another person had another fork named the same thing but re-written in coffeescript.

We have all new problems now because of the size and growth rate of the registry, but we couldn't even have these problems if we didn't get an insane amount of investment already in the ecosystem, investment that was encouraged and benefited from a global namespace. 

Whatever our new problems are we can't take back the global namespace, it's too far along and too engrained in to how we publish things.

Discoverability does suck now, and for entirely other reasons, and Isaac has some good ideas about improving that which I hope to see show up on npmjs.org pretty soon.

When we propose new ideas for helping solve the new problems that we have I'd like to put two guiding principals forward.

1. Module problems and people/community problems.

2. Community problems are solved socially more than technically.

We can write some great new code that incentivizes people to write "better" modules, we can create better social tools that push us in a direction that suites our own styles and preferences more, but what we can't do is create anything close to "empirical" numbers or ratings that give us the "best" module.

At the end of the day someone investing in the community is always going to find better modules than someone who isn't, we can't entirely replace that investment as a tool for discovery but we certainly can make it easier than it is today.

-Mikeal

[Mark Hahn]

>  and another person had another fork named the same thing 

I hate the fact that when you fork something in github it inherits the same name, same readme, etc.  Many times I thought I had found the origin of a project because I didn't notice the fine print.  And, for some reason google will occasionally return a fork ahead of the original project.