On Thu, Jun 28, 2012 at 11:41 PM, Isaac Schlueter <[email protected]> wrote:
> 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"}
>
The problem with your solution is you're still allowing backtracking. A
*much* more common scenario would be someone writes a first version of a
package, without knowing much about npm or package.json contents, and
publishes it. Maybe a few versions. Then he gets bug reports that it does
require('domain') and so only works on 0.8+, so adds in the engines: tag to
"fix" this. After all, that's what the docs indicate it does. What the docs
don't indicate is that he now also has to delete all old versions of his
module, because otherwise npm will just install it anyway on 0.6.
I still didn't see a valid argument as to why we can't error out (instead
of warning) if the engines doesn't match. It seems like even with
enginesStrict: true you haven't actually fixed anything, because node will
still go back in history trying to find a version that will work.
Why is trying to go back in history to find a version that matches so
important? If users want a specific version they can do that in
dependencies - if they don't specify that, why would you *ever* want to
give them anything other than the latest version?
Matt.
--
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
