
Npm Private Modules - mts_
https://www.npmjs.com/private-modules
======
BinaryIdiot
So this reads to me that they're simply not going to update the ability to use
GIT. Right now you can point to a repo or specific branch / tag but it doesn't
read any of the versioning like bower does, so it can't handle versioning
properly. If they updated the use of GIT you could completely eliminate the
need for this feature.

That kinda rubs me the wrong way; it feels like they're trying to force this
monetization as they've had plenty of us from the community wanting better GIT
support for this very reason.

Honestly npm isn't a very complex piece of software, you could even replace it
with bower if you want git with versions. I wonder if any competitors are
going to spring up who can simply iterate faster. I won't even get started on
their login system, ugh.

~~~
warfangle
> Right now you can point to a repo or specific branch / tag but it doesn't
> read any of the versioning like bower does, so it can't handle versioning
> properly.

You can even point to a specific commit hash. But no, it doesn't read any of
the versioning. What if two different branches have the same version number?
The publish step is pretty important, because ...

> If they updated the use of GIT you could completely eliminate the need for
> this feature.

... You'd still miss out on the prepublish hook - one of the major reasons
I've looked into using NPM Enterprise.

Sometimes your package needs to do some housekeeping _before_ you publish, and
the files generated by that should be distributed -- but not checked into
source control.

~~~
Touche
> You can even point to a specific commit hash. But no, it doesn't read any of
> the versioning. What if two different branches have the same version number?

The semver mechanism would be based on the tag, so it would not work when
pointing to a specific commit hash (and you wouldn't want it to).

> ... You'd still miss out on the prepublish hook - one of the major reasons
> I've looked into using NPM Enterprise. Sometimes your package needs to do
> some housekeeping _before_ you publish, and the files generated by that
> should be distributed -- but not checked into source control.

That's a nice feature and all but not required to have proper git support.

------
archgrove
We're already using "private" modules, by hosting them in a private git repo.
NPM can install from these, e.g., git+ssh://user@server:Account/Repo.git,
without problems. I'm not sure what value this would add for us, and the URL
doesn't sell me well on it.

~~~
seldo
We're glad private repos work for you :-) However, the overwhelming feedback
from our users has been that git dependencies are a gigantic pain in the neck,
and this has been our own personal experience as users of npm. Much like npm
itself, we are doing something you could do without npm, it's just much easier
with npm, and we hope that reduction in friction is valuable :-)

~~~
thom_nic
Is it modeled strictly per-user or is there any notion of an "organization"
similar to Github? It's hard to imagine a business having to manage paying for
a bunch of individual accounts so they can have access to the company's
private repo.

~~~
mts_
Organization accounts are coming soon:

    
    
      Currently, private packages are only available for individual users, but support for organization accounts is coming soon. Feel free to create a user for your organization in the meantime, and we can upgrade it to an organization when support is here.
    

[https://www.npmjs.com/private-
modules#organizations](https://www.npmjs.com/private-modules#organizations)

------
joesb
IMHO, tying language's defacto package management's capabiity to a single
company's business model may hurts node.

No other language does this. you have all the same capability for propretary
package with RubyGem/Python/Nuget, even Ubuntu allow you to add third party
package repository.

It gives me the clue that npm may no longer improve, or many improvement will
be "premium" feature.

I hope someone fork npm and add ability to parse semver from tag for github
repo.

------
mts_
Everything looks pretty awesome, except the payment model.

I'm a little surprised they didn't go with a model similar to GitHub: \-
Payment plans with X number of private modules, or $1/month per private module
\- Unlimited paying/non-paying collaborators for private modules (perhaps only
read access for non-paying)

With npm's model all my collaborators will have to pay for npm private modules
as well.

~~~
substack
Charging per-module like github would encourage people to author fewer
packages and to lump more functionality into the same package, which goes
completely against the ethos of npm and the spirit of tiny abstractions that
do one thing well.

The way that npm has structured things, programmers pay once for membership in
a commercial tier, where presumably money is already changing hands to work on
private code. I think this makes much more sense and won't bias the code
itself in a negative direction.

~~~
mts_
That's a very good point!

I hadn't thought of it from the point of encouraging/incentivizing the
authoring of more public packages.

But couldn't the current model then discourage the authoring of public
packages, and lead people to start primarily publishing private packages.

I assume whatever reason people are authoring public packages today won't
change because they get a paid account. Let's at least hope that's the case.

------
skrebbel
Does anyone know whether the open source NPM implementation allows me to
implement and host my own private repository system without forking npm? Or is
npm (and thus node and iojs) hard-tied to npm, Inc's proprietary offering for
private modules?

~~~
altcognito
Nexus serves NPM packages, Ruby GEMs, YUM packages and also serves as a Maven
repository.

[https://books.sonatype.com/nexus-book/reference/npm-
configur...](https://books.sonatype.com/nexus-book/reference/npm-
configuring.html)

Source code: [https://github.com/sonatype/nexus-
oss](https://github.com/sonatype/nexus-oss)

~~~
Osiris
One of our DevOps guys setup Nexus to serve npm packages. It both allows for
the publishing of private repos (meaning you get semantic versioning support
unlike git links) and caching of public repos from npm. It works extremely
well.

------
laurencerowe
The Python equivalent to this is to simply place your source release tarballs
on a simple private web / filesystem directory:

    
    
        pip install --find-links http://dist.example.com/packages/
    

This also makes it simple to mirror all requirements locally for more reliable
installs.

I wish I could do the same with npm.

------
talles
If anyone is wonder the pricing like me just head to the home page: "publish
unlimited private modules for just $7/month".

Here's a question: people with read-only access (to my private packages) have
to be paid users too?

~~~
LukeB_UK
From the page:

> Give read access or read-write access for those packages to any other paid
> user

~~~
talles
My bad, I completely missed that.

So in the end is $7 per user, you can't have just one paying user publishing
for everyone else. I guess I'll have to wait for _organizations accounts_ for
now.

------
kennethh
Suggestion, add a pricing link? I usually do a ctrl-F to search for pricing in
a service like this, make it easier for me to find.

~~~
NietTim
If anybody else is wondering, it costs $7 per month (per user)

------
jbob2000
I'm fearful of where this monetization is going. Part of what I like about npm
is that everything is free, from the dinky little packages that do one thing
really well, to the monumental ones that provide a host of functionality.

I would hate if NPM went the way of wordpress plugins, where every stupid
little plugin costs $5 to access.

------
nabaraz
I might have missed the obvious but what is the difference between this and
hosting your own private git repository?

------
laggyluke
And now it's down:

[http://status.npmjs.org/](http://status.npmjs.org/)

~~~
laggyluke
And back up, but you can see a dip on charts.

------
yellowapple
Somewhat off-topic: "NPM Private Module" would be an excellent recursive
acronym.

------
amelius
I recently got interested in nodejs. However, then I discovered that:

1\. It doesn't support threads (facilitating structural sharing of large data-
structures between parallel tasks, which cannot be done using ordinary
processes).

2\. The module-loading mechanism ("require()") natively doesn't support
delayed loading, which is needed when loading from within a browser. Yes,
there is the "browserify" package, but, come on, something as basic like this
should be supported out of the box. Especially considering the fact that there
is a "http" module hardwired inside nodejs (why isn't this a separate npm
module, btw?)

3\. To make my own privately held modules and install them properly, I have to
run a npm server? This seems like an awful lot of work for something as basic
as this. Ok, so now I can use the cloud for this, but come on, I should be
able to do this just from within the filesystem, like e.g. git does it.

For people interested, one can use the package "sinopia" for hosting your own
private modules. It seems to be a pretty decent package, but be aware that the
authentication settings out of the box are completely insecure.

~~~
TomFrost
1\. Node.js is (for the most part) single-threaded; that's its draw. It's not
trying to be a swiss army knife, and if your use case requires a threaded
language then Node.js certainly isn't the tool for that job. But it might find
a useful place in your toolbox for other tasks.

2\. require() is part of the CommonJS spec, and how it physically works is
dependent on the implementation. You point out that Node's implementation
doesn't work well in the browser, but Node itself does not work in the browser
so that point is moot. I agree that it might be interesting to load remote
modules in Node, but keeping that operation synchronous does simplify the
language quite a bit.

3\. You can also map modules to public or private git repositories in the
package.json, as long as the private key used during npm install has access.
If the git repo has tags, a tag can be specified in the git uri as well.
Private npm repos are the superior way to distribute private modules with
wider access, but I think this is handled fairly cleanly already.

~~~
amelius
Thanks for your comments. Some remarks here.

1\. Node.js is a tool for building servers. On a server you generally cannot
afford to have the event loop blocked by a computational intensive task. You
need threads.

2\. It would only require a "promise" to make the module-loading asynchronous.
Leaving that out is not what I would call "quite a bit of a simplification",
especially if using asynchronous callbacks is the "modus operandi" of
programming on the Node.js platform itself.

3\. Okay, I stand corrected. I remember that I waded through the documentation
quite a bit though, trying to figure this out.

~~~
emilsedgh
_On a server you generally cannot afford to have the event loop blocked by a
computational intensive task._

You are not supposed to use your main event loop for computational intensive
tasks.

Offload those tasks to separate workers and use queues.

That's node's basic knowledge. Its a trade off that you're supposed to be
aware of when using node.

~~~
amelius
The problem with workers is that they don't have an event-loop (like the main
thread). So it is not possible to use asynchronous code written for the main
thread in those worker threads, which is of course quite limiting.

EDIT: I mean workers which run in a thread (as opposed to in a process). An
example is given by the webworker-threads npm module. Threads allow one to
structurally share large data-structures, so one does not have to serialize
them when calling a worker (serializing large structures would block the main
thread).

~~~
NathanKP
Sorry you are getting a lot of downvotes. For what it is worth I don't think
you deserve them, as your comments just show inexperience and lack of
understanding of Node.js, and aren't trolling. However, I think you would be
well served by doing some research into what Node.js and and how it works.
Basically every Node.js process has an event loop. Your workers have an event
loop just like your servers do.

Here is how a typical node stack works:

Nginx load balancer talks to a cluster of node server processes, one per core.
The server processes handle all incoming web requests that won't block the
event loop. On a typical REST server this is 99% of your tasks, and each node
process can handle thousands of concurrent requests due to the way that the
event loop works.

If there is a heavy, blocking task like processing an image or PDF file,
(although even these things should be able to be done in a nonblocking stream
manner) the server processes send a message through a background queue such as
RabbitMQ, or Amazon SQS or the like to a background process which has the sole
purpose of processing heavy tasks pulled from that queue. Fundamentally if you
are using Node.js properly you don't need multiple threads. Instead you use
multiple processes, and the processes are essentially "threads" that can talk
to each other either using parent/child processes communication, HTTP, redis
pubsub, or any other mechanism you want.

But there is no reason why anything should block a Node.js process if it is
written properly. I've even done heavy video transcoding in a streaming manner
in a Node.js process without blocking the event loop.

~~~
amelius
Thanks for the explanation and the moral support :)

I think most people here misread the line "facilitating structural sharing of
large data-structures between parallel tasks, which cannot be done using
ordinary processes" in my first post.

And by large data-structures, I don't necessarily mean structures which can be
"naturally" streamed. I'm thinking more of a large index, for example, which
can be used for fast lookup, and be used from several threads at the same
time.

Having processes (here named workers) is a nice feature, but doesn't cut it
when you want to share large amounts of data between threads (serializing that
data would completely block the main thread). In my view, it is unfortunate
that the designers of Node.js didn't opt for having multiple threads as
opposed to putting every thread in a separate process.

~~~
NathanKP
I ended up replying to one of your other comments with more details but the
answer to this problem is streams. You can use streams for any and all
incoming data, whether it is file data uploaded via multipart upload from a
browser, or streaming result set from a database, or raw data streaming out of
a storage service like S3 or Dropbox. There is even a streaming JSON parser
for Node.js in case you have the ungodly situation of having say a 500 MB JSON
file or something horrible like that: [http://oboejs.com/](http://oboejs.com/)

