Vitaly, In practice, what happens is that a new version of Node comes out, and no one can use it until everyone else uses it, which is not great for me or for this community. We need to be moving forward. In a lot of cases, the metadata was reasonable at the time, and added by `npm init`. We encourage the creation of many hundreds of small reusable modules every day. We can't then turn around and penalize people for using the tools, or expect that they spend lots of time doing boring hoop-jumping maintenance.
It's done: https://github.com/isaacs/npm/commit/ee1d168d7a4798b67bb9a7667b5ec93a8be3d953 Engines is advisory. It prints a warning. Set `engineStrict` in your package.json, or `--engine-strict` config, to make it strict. (If the package.json field is abused, it will be removed eventually. I don't suspect this is going to be an issue.) On Wed, Jun 27, 2012 at 6: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 >> > 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
