I'm -1 for reducing it to a warning. By doing that you're taking the opposite assumption, that the person who wrote the package doesn't know what he/she's doing. What if the package uses domains and puts in engines: ">=0.8.0" ? By reducing it to a warning you're letting people's code fail at runtime instead of at install time.
On Wed, Jun 27, 2012 at 3:13 PM, Dan Shaw <[email protected]> wrote: > I'm +1 for reducing it to a warning and letting infrastructure > companies build, adapt and extend it to their needs in userland. > > Daniel Shaw > @dshaw > > > On Wed, Jun 27, 2012 at 10:45 AM, Isaac Schlueter <[email protected]> wrote: > > Thanks for the feedback, everyone. > > > > It seems like we can achieve the optimum balance like this: > > > > 1. add an "engines-strict" config, default false > > > > 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 > >> 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 > > > > -- > > 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 > -- 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
