Matt,
What you describe is rare. Engines causing unnecessary pain is
*extremely* common.
As it stands, like I said, the prior behavior didn't really solve your
problem. In fact, it made it worse. (Silently installs the older
unsafe version.)
What you need to do in that case is with the new behavior is:
1. Remove the old copies of the module.
2. add to package.json: "engines": {"node": ">=0.6.16"}, "engineStrict": true
What you had to do with the prior behavior was:
1. Remove old copies of the module.
2. add to package.json: "engines": {"node": ">=0.6.16"}
So, for this fairly rare exception, you have to add a few extra bytes
to your package.json file (and people will be more likely to actually
*notice* the failure, because it won't be "Oh, yeah, that means i have
to -f it", it'll be "Wait, wtf?!"). Even if you don't add the strict
flag, users will get a warning, whereas before, they'd get the wrong
thing silently.
What we get in return for this overhead is *everyone else* gets to
upgrade with way less pain in the much more common case.
You are making this discussion about something it's not. The
"engines" field was never intended to be used as a way to guard
against security problems, and it has never been an effective way to
do so.
If you have a security problem in a package, unpublish it. If you
want to make a package "FAIL HARD", then add
"scripts":{"prepublish":"exit 1"} and it will fail as hard as
possible.
--
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
