| 1 |
On Wed, Aug 20, 2014 at 11:08 AM, Jesus Rivero (Neurogeek) < |
| 2 |
neurogeek@g.o> wrote: |
| 3 |
|
| 4 |
> I originally responded to another thread. Here is what I said: |
| 5 |
> < |
| 6 |
> I gave this a try some time ago and was bummed down by some things. I dont |
| 7 |
> like nodejs enough, and npm devs seems to not care about centrally/globally |
| 8 |
> installed packages. There are some npm packages that have to be modified so |
| 9 |
> they can work when globally installed and it gets boring after a while. npm |
| 10 |
> packages tend to be really small so one package can have a really high |
| 11 |
> number of deps. |
| 12 |
> |
| 13 |
|
| 14 |
For NodeJS, the first-class thing is web applications, and as far as their |
| 15 |
concerned, the "best practice" is, if your application uses a library, it |
| 16 |
should have its own copy of it. And, for web applications, that *does* |
| 17 |
guarantee that you know what version of everything you're deploying, and |
| 18 |
allows an application to have dependencies which themselves have |
| 19 |
conflicting dependencies - which helps ensure deployment is uncomplicated |
| 20 |
and you know what you're deploying. |
| 21 |
|
| 22 |
However, globally installed packages are supported, and are increasingly |
| 23 |
important as people discover NodeJS is useful for things that are not |
| 24 |
web-application related. So it seems like something that's not going away, |
| 25 |
and sooner or later package managers will have to deal with it. |
| 26 |
|
| 27 |
|
| 28 |
> If anybody is interested in this, check out my repo with npm packages[0] |
| 29 |
> and a really simple g-npm tool[1] to generate ebuilds for them. These tools |
| 30 |
> might be outdated cause I don't use nodejs anymore and I dont care much |
| 31 |
> about it. |
| 32 |
> |
| 33 |
|
| 34 |
g-npm looks interesting. |
| 35 |
|
| 36 |
-Tim |
Archives