Isaac, so, in strict mode, do we still have the funky fallback logic where it tries to get the next best version of the package to satisfy the current environment? If so, I think we should change it to only attempt the preferred version and either warn or throw depending on the strict flag.
For example, I published a version of vfs-local that allowed any node version >=0.6.0, but then later found out that node itself had a nasty security hole that was fixed in 0.6.16. I don't want anyone running my code in an older node, so I add the strict flag to my package.json flag and leave the open-ended >=0.6.16 range for engine. So what happens then when someone on 0.6.15 tried to install my library. Will it throw an error, or will it load the previously published version that had the >=0.6.0 constraint and the nasty security hole? On Wed, Jun 27, 2012 at 8:16 PM, Isaac Schlueter <[email protected]> wrote: > 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 > -- 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
