"Broken metadata is just broken metadata" This hits the nail on the head. This fix to me feels very short-sighted and PHP-y to me. If this is a bad problem I feel the correct solution would be to add a flag to npm install such that you could skip the engines check: `npm install --force some-legacy-package`.
Regarding engines, I'm using it in node-fibers.. "node":">=0.5.2". There are older versions of fibers that work with older versions of node, and those are also marked correctly in their metadata. On Wed, Jun 27, 2012 at 8:09 PM, Vitaly Puzrin <[email protected]> wrote: > You try to make magic in place, where it is scrictly unwelcome. > > Broken metadata is just broken metadata, but not the problem, that should > be solved in npm. > If package is not updated for ages and has wrong dependencies - just let > him die. > > среда, 27 июня 2012 г., 21:45:51 UTC+4 пользователь Isaac Schlueter > написал: > >> Thanks for the feedback, everyone. >> >> It seems like we can achieve the optimum balance like this: >> >> 1. add an "engines-strict" config, default false >> 2. If "engines-strict" == true, then the current behavior. >> 3. if "engines-strict" == false, then it's a warning >> >> Then Heroku and Azure and the like can set the flag in their envs if >> they want to (or just look at the engines value and do whatever they >> want with it), and users will be alerted about the need to upgrade >> (but without being forced to, or as is more often the case, forced NOT >> to.) >> >> Adding checking for "or higher" would seem to be too subtle a change >> to me. Ie, if your package says `"engines":"0.4.x"`, and I have node >> 0.8, do you *really* mean >=0.6.0? Or do you mean that you rely on >> listenFD, which is gone in 0.6, and reimplemented in 0.8, but somewhat >> differently? >> >> It seems like the better option is just to warn you that it might >> break, and then let it break. >> >> Another option might be to let authors add an "enginesStrict" boolean >> flag in their package.json which would say, "No, seriously, this WILL >> NOT WORK except with the specified versions, so don't even try to use >> it." >> >> What we're seeing in practice is just weird and broken behavior, >> usually because an old version of something (say, a package from 2 >> years ago, which doesn't work on modern node) might have no engines >> specified, but a newer version of the same package (which works fine >> on 0.8) has "engines":{"node":"0.6.x"} specified. So, npm tries to >> find the most recent version that it thinks will work, and it gets >> 0.1.2 (which is broken and old) instead of 4.8.12 (which is new, and >> works). That's the opposite of the intent. A nag would be more >> appropriate in that case, I think. >> >> >> >> On Wed, Jun 27, 2012 at 8:50 AM, Glenn Block <[email protected]> >> wrote: >> > We were just about to take a dependency on it for Azure. Is there an >> > alternative recommended approach? I believe Heroku uses this as well. >> > >> > Sent from my Windows Phone >> > ______________________________**__ >> > From: Bradley Meck >> > Sent: 6/26/2012 10:09 PM >> > To: [email protected] >> > Subject: [nodejs] Re: remove "engines" from package.json? >> > >> > At least some PaaS use it. I think it it were tied to tests in some way >> it >> > would be more meaningful for the average user, but for now it most >> commonly >> > used for PaaS deploys. >> > >> > On Wednesday, June 27, 2012 12:06:52 AM UTC-5, Isaac Schlueter wrote: >> >> >> >> Do people actually rely on the "engines" hash being respected in npm >> >> installs any more? It was super essential in the early days when the >> >> API was changing constantly, but now, it seems like it just makes it >> >> unnecessarily difficult to upgrade stuff. >> >> >> >> If no one is relying on this right now, I'm going to reduce it to a >> >> warning. If in time, people start complaining that the warning is to >> >> warny, we can remove it, and just let "engines" be a thing of the >> >> past. (Note that `npm init` already doesn't bother with it, and for a >> >> while has just defaulted to {"node":"*"}.) >> >> >> >> Please let me know what you think. Thanks :) >> > >> > -- >> > Job Board: http://jobs.nodejs.org/ >> > Posting guidelines: >> > https://github.com/joyent/**node/wiki/Mailing-List-**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 >> > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >> > For more options, visit this group at >> > http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en> >> > >> > -- >> > Job Board: http://jobs.nodejs.org/ >> > Posting guidelines: >> > https://github.com/joyent/**node/wiki/Mailing-List-**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 >> > nodejs+unsubscribe@**googlegroups.com<nodejs%[email protected]> >> > For more options, visit this group at >> > http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en> >> > -- > 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 > -- 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
