HN Explorer

35 comments

[ 3.3 ms ] story [ 77.3 ms ] thread
dexwiz
Analytics shouldn't break applications. If anything npm should provide a way to opt into analytics and provide them to all publishers.
kuschku
Even worse, they’re doing analytics without opt-in, or providing a way to use the package without analytics.

This is clearly inacceptable.

forgottenacc56
Unacceptable
kuschku
See, this is why I don’t like english. in- and un- both should mean the same, why I can’t I use them synonymously?
grawlinson
All languages have their own idiosyncrasies, not just English. I'm a native speaker of 2 different languages and I find that there is still more to learn about them via small mistakes that I make.
[deleted]
(comment deleted)
majormjr
Inflammable means flammable? What a country!
ntumlin
I'm aware this is a reference, but for people who didn't know this already, inflammable is like the word inflamed, which doesn't mean "not in flames".
striking
Or, just provide anonymized public analytics.
davidbanham
This isn't npm doing analytics. It's the package manager abusing a dependency declaration and a preinstall script to do their own private analytics.
amluto
One might reasonably wonder whether executing npm outside a sandbox is a good idea under any circumstances.
avita1
But they can't be stealing any identifying information right? At best it can count the number of times the package was downloaded.

Isn't the solution for npm to have tighter controls on where it will download packages from?

STRML
It depends on whether or not it actually delivers a payload. If it does, then it can use a `postinstall` hook to execute absolutely anything it wants, under the context of the user.

This is why you should always shrinkwrap and run a private npm repository in production. Anything less is opening you up to remote takeover at the whim of a single package publisher.

hitekker
Between this and the other article regarding the death of ExpressJS-- is IBM is a good contributor to the JS open source community?
__derek__
Did you read the GitHub thread on Express? The project is still very much alive, but its internals have been broken out into standalone packages, so the only commits to Express itself are version updates. That issue was created based on a misunderstanding.
plorkyeran
If you read further down on the Github thread, the guy who did the splitting out is no longer working on the project and it's now fully in IBM's hands, who aren't doing much of anything.
__derek__
I just saw that! I read it a few days ago, but went back to catch up. I came back to edit my comment.
__derek__
This appears not to be the case, so it's me who's saying things based on misunderstandings now.
STRML
This actually happened well before IBM acquired StrongLoop - I first noticed it in February, but it was added in January 2015. The IBM acquisition was announced in September 2015.

In their usual fashion they link to internal bug trackers when committing (without summary), something that has frustrated me greatly while attempting to work with them on strong-remoting and loopback-explorer.

nodesocket
`curl -i http://blip.strongloop.com/loopback` returns content from S3. Are we suggesting then they are using S3 bucket analytics to see how many times a package has been downloaded then?
[deleted]
(comment deleted)
brillenfux
I have long since come to the conclusion that most of the nodejs ecosystem is rotten. I don't even know where to begin.

I'm certain this is a mentality issue more than anything.

pearjuice
Greed for authority, power and influence is what is causing that rot.
untog
I just think that the nodejs ecosystem moves fast. But anything involving StrongLoop/IBM is immediately suspect.
edwinnathaniel
Just strongloop is enough. IBM acquihire them and let they do what they have been doing...
cpeterso
Should the HN title include "(2015)"? This StrongLoop issue was reported in February 2015.
STRML
Perhaps. I opened it a long time ago, but I've still been trying to keep it alive in the hope that somebody from Strongloop will actually comment on it.

In the meantime, if you use a Strongloop package, fork it and remove the optionalDependency.

striking
I had no idea this existed.

...this basically invalidates any sort of use Strongloop has for tracking its users via optionalDependencies.

Thanks for that.