error when using with node 0.10.4

[gudurisaiteja]

given it is supported for node>=0.10.0

our legacy application is using node 0.10.4
I have include fb v 1.1.1 in package.json
and did npm install
when I am running my app it is giving below error

/app/node_modules/fb/node_modules/boom/lib/index.js:5
const Hoek = require('hoek');
^^^^^
As node 0.10.4 didn't support es6 syntax it is not able to run
any solution to resolve this?

[dantman]

That version of this module is transpiled to es5. The issue is in dependencies, request is requiring a version of hawk which it and its dependencies only support node@4+. You can try downgrading to [email protected] by installing request@~2.67.0 directly (this package uses ^2.67.0 which installs the current version of request, 2.82.1).

This appears to be request's fault, they're violating semver. Instead of releasing a 3.0 when they made the breaking change of dropping support for node 0.10 they instead released that as version 2.77.0.

I'm not going to do any more than that to support 0.10, because that version of node is explicitly marked as End of Life and stopped receiving security patches a whole year ago. Absolutely no one should be using it, even for legacy applications.

[dantman]

Relevant upstream issue:
request/request#2772

[dantman]

Actually considering that [email protected] is still present in a LTS version of Debian supported until April 2020, I might reconsider this.

If request refuses to guarantee that it won't change the nodejs minimum version without making a breaking change I may make a point release to all the latest major releases of this library pinning request to a specific ~ version of request.

[mikeal]

Actually considering that [email protected] is still present in a LTS version of Debian supported until April 2020, I might reconsider this.

This is irresponsible. There are, today, known security vulnerabilities that will not be fixed. Do not support/encourage users to continue running it.

[mikeal]

Note that if you pin request in order to continue supporting 0.10.x you will also be opted out of security updates of request, and there are already several since dropping 0.10.x support.

[refack]

considering that [email protected] is still present in a LTS version of Debian supported until April 2020

Is the Debian Project willing to take over fixing [email protected]?
P.S. IMHO a bug about this should be filed to Debian.

[dantman]

Note that if you pin request in order to continue supporting 0.10.x you will also be opted out of security updates of request, and there are already several since dropping 0.10.x support.

You're right, if request can't stick to sane version ranges (being unable to pin my package to the range of request versions that will work along side it without also losing access to security upgrades), then instead of trying to pin to a minor version I should probably just stop considering request to be a viable package to use in my libraries or my applications and just switch everything to one of the other nodejs HTTP libraries.

[mikeal]

@dantman or, and hear me out on this, you could stop supporting EOL and insecure versions of Node.js.

[dantman]

Is the Debian Project willing to take over fixing [email protected]?
P.S. IMHO a bug about this should be filed to Debian.

Debian backports security patches to their packages, even when the upstream project considers that release EOL and isn't patching it. For example they patched the CVE-2017-1000381 vulnerability in the c-ares library used by node.js, which node.js only patched 4+ with a fix for. So the official [email protected] release is vulnerable to that CVE, but the [email protected]~dfsg-2 package in Debian jessie is not.

@dantman or, and hear me out on this, you could stop supporting EOL and insecure versions of Node.js.

As I just pointed out, it appears that [email protected]~dfsg-2 is not an insecure version of Node.js. And support is irrelevant, I just want to make sure that installations of previous releases of the library I'm maintaining don't suddenly fatally break in versions of node they are coded against because you personally decided that it was ok to break them, leading to bug reports in my issue tracker about bugs you introduce.

If you can't stick to semver, then your library is not a good package for me to make my packages depend on.

Other http request libraries appear to stick to semver, the packages request depends on to implement the fancy featues follow semver. The only piece in this puzzle that is causing things to break, is request.

[dantman]

Another note I should make for myself. request pulls in a lot of dependencies, like hawk, aws*, oauth-sign, ajv/json-schema, har, and more all which we do not have any use for. This makes request pretty bloated, totalling up to 5.7MB currently. And pretty problematic (loading a bunch of packages that we don't need putting them uselessly into memory; and then they are typically the cause of problems, like how hawk's use of es6 is what threw this error in the first place, despite it being an unused library).

Now that node supports iterators I should consider toning down the use of the core-js and regenerator polyfills and replacing request with something that doesn't pull in a bunch of code we have no use for.

[dantman]

I can't really go back and retroactively fix 1.1.1 at this point. But request has been replaced with needle now for 3.0. So at least once 3.0 is out and everyone is on it there shouldn't be any more surprise semver breakages. And we don't have to pay attention to security vulnerabilities in packages like hawk, aws*, and har that we don't use.