New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Same issue with 0.2.12. Expected version ">=6.0.0" #17
Comments
Edit: Talking out of my ass, please disregard. :) I didn't read carefully enough and jumped to conclusions. |
@CobaltTiger for why something that wasn't "broken" got fixed, see https://medium.com/@jasnell/node-js-buffer-api-changes-3c21f1048f97#.wniv7cqhz and nodejs/node#4660. Because there are no external API changes which would warrent a minor release, and there are potential security concerns, which is what |
@jh2oman |
@CobaltTiger if you get a second can you give me a stack trace using |
@brianloveswords thank you very much. Unfortunately out until after Thanksgiving so I won't be able to verify till then. |
@jh2oman sorry I wasn't able to get to it until you were out, let me know if it fixes your issue once you get back and I'll close this. Thanks! |
@brianloveswords Aha, security issues I can completely understand. I had not seen these writeups -- and even at a glance I can see that being an issue that would indeed be best addressed through a patch. As far as a stack trace goes, I'm unfortunately not able to easily produce one. In my case, the offending first-level dependent is a plugin called grunt-aws-lambda, which leverages archiver ~0.14.4. It proceeds to call npm.load and set its log level to silent. :) I do see that its only interaction with archiver (which, itself, seems to be the culprit as it is the only thing using buffer-crc32) is that it creates an archiver('zip'); If you really need the stack trace, I can try tomorrow to make that child npm process more talkative. |
@CobaltTiger yeah, the stack trace would help – |
@brianloveswords I think recently publish versions broken a lot. And I think those verions should be 0.3.x not 0.2.x. |
I feel like yeah, if it does have to go to a new minor version, 0.2.x On Mon, Nov 21, 2016 at 10:15 PM, fengmk2 notifications@github.com wrote:
|
@fengmk2 please file an issue with a stack trace if you're having one. There's definitely been some churn with this update to the new Buffer APIs while still trying to remain backwards compatible, which I take responsibility & apologize for, but I believe it's in the best interest of the community to provide this as a patch update. |
@brianloveswords I'm sorry, I'm unable to produce a stack trace on my end. I did notice that npm was pulling down only 0.2.8 in previous builds -- perhaps that's the crux of the issue. -- Confirmed that the previously mentioned build problem is NOT present when using 0.2.13 -- my apologies for the confusion. I failed to notice it at the time, but even as of 7pm EST, npm was still pulling down v0.2.8 for some reason. Which is equally weird, since the only dependencies we've got are requesting buffer-crc32@~0.2.1, which should have picked the latest version... Or it could've been an unfortunate caching/proxy incident, since we proxy the npm repo through Artifactory, and it's proven to not always be the smartest. :T |
@brianloveswords 0.2.13 Fixes my issue. Thank you very much! |
@jh2oman great, thanks for following up and sorry again for breaking it! |
The engine "node" is incompatible with this module. Expected version ">=6.0.0".
node -v
v4.5.0
The text was updated successfully, but these errors were encountered: