Matt,

> Why is trying to go back in history to find a version that matches so
> important?

It's important because there is a much more common case than the one
you're describing:  You write version 1.0 with node 0.6 in mind.  Make
changes, updates, yadda yadda.  Then 0.8 comes out, and you add
support for that.  You release 2.0 with the engines setting on it.

For a while, you may even be releasing updates to both the 1.0 and the
2.0 versions!  So, you'd prefer to have 0.6.x users get the 1.0.latest
and 0.8.x users get the 2.0.latest.

I'm not saying that the backtracking behavior we've had is perfect,
but it's what's been there for a few years.  The change you're
suggesting is significantly more subtle and has more side effects than
simply making engines advisory, with the option of opting into the old
behavior.

When in doubt, make changes that are minimal and easily reverted.

On Fri, Jun 29, 2012 at 6:32 AM, Matt <[email protected]> wrote:
> 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.

My goal was to fix a specific scenario: Authors putting
"engines":{"node":"0.6.x"} in their package.json files, with the best
intentions (or no specific intentions), and then ending up with dozens
of little annoying barbs preventing their users from upgrading.

The problem you're talking about is different from that.  This doesn't
make it any worse (though, admittedly, it doesn't make it much better,
as you've pointed out).  If we address that, it'll be a separate
thing.

In the meantime, you DO have the capacity to add arbitrary commands to
your package.json file that can be run at various points in the
install process.  Check out `npm help scripts`.  Nothing's stopping
you from adding a script that checks the node version, the price of
tea, or the phase of the moon, and aborts if things are not good.

-- 
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

Reply via email to