Closed cwalther closed 3 years ago
I can confirm the bug with node v7.10.1 (in a buildsystem Yocto, so it's not easy to fix - we will need to pin a specific older version)
It's probably because of #370. I'll check and fix it a minute.
reproduced with node 8.10.0 (I'm here from a dependency of less@4.1.1)
Same here, had to downgrade to 2.8.0 in order for it to work.
It's probably because of #370. I'll check and fix it a minute.
https://nodejs.org/api/stream.html#stream_stream_pipeline_source_transforms_destination_callback
I think it's because stream.pipeline
was added in Node.js v10 (based on the History log there)
I think I have it working now (branch pump-module
). I'll run a few more tests and merge in a while.
I assume you switched to https://www.npmjs.com/package/pump?
It's a bit old (last update 4 years ago). I hope it works as well as stream.pipeline
. Haven't used it for a long time!
I did try using that module and that's why the branch is called that way, but I ended up removing it because it didn't make any difference as a replacement for stream.pipeline.
@tomas - I actually ran into a really, really specific failure[1] that I ultimately tracked down to this same issue despite there not being any old node versions involved (running node v14.17.1 locally and v14.17.0 on our Jenkins).
The good news is that your pump-module
branch does resolve the problem.
[1] Specifically, we have a dependency that we publish for a bunch of internal Nuxt apps. That common dependency itself runs splunk-logger, which depends on needle. When that dependency was published to our Nexus instance and the app was running locally and running in dev mode then we got the same > TypeError: Cannot read property 'apply' of undefined
error.
We use yalc for local development; it did not happen when we were using the local yalc version.
It worked fine when we built it on our Jenkins instance, regardless of whether we ran it in dev or production mode.
And it worked fine when we ran it locally in production mode.
Literally, the only condition where it was a problem was when the Nuxt app was running locally in dev mode and using the Nexus published version of our dependency that has needle as a transitive dependency.
Hey @metasean, I already merged the pump-module
branch into master and added a few other fixes. Can you try and see if it works OK for you? Haven't pushed a new release yet.
@tomas - Using your master
branch, I just ran a couple of our apps through all the environments and conditions that I can think of and everything's coming up roses. 🥳
Thank you!!!
"Coming up roses", I think I'm going to put that in the readme, haha.
Excellent!
Confirmed, the example I tried seems to work again with node v8.10.0 on Ubuntu 18.04 with master. Thanks! Unless there are any other concerns about it, I would appreciate if this could be released as soon as possible.
Already pushed v3.0.0
to npm
Hmm, but that doesn’t help me, because it means that a package like node-pre-gyp
(my sub-dependency) that requires "needle": "^2.2.1"
will remain broken. Could we have a 2.9.1 or 2.10.0 that is fixed (and does not have whatever breaking change it is that is implied by the major version bump to 3.0.0)? If nothing else, simply equal to 2.8.0 or to 2.9.0 with #370 reverted?
I'm not sure if its possible to push a version number lower than the already published version, but if possible then sure, I can publish the fix as v2.9.1
.
Any progress? Our builds are still failing…
(Yes, it’s our own fault that the build is that fragile and we should be pinning our dependency versions using package-lock.json or npm-shrinkwrap.json, but last time I tried that it caused other problems, and I just don’t have time right now to spend a lot of effort on our Node.js stuff, so I was hoping the problem could be solved as quickly by an upstream update as it was caused by an upstream update, without me having to divert effort from more important things.)
@cwalther Just published v2.9.1
with the fix.
Maybe you can buy me a coffee sometime. :)
@tomas - fwiw: I'm not seeing v2.9.1
in either the releases or tagged versions.
(And if you have a buy me a coffee, Patreon, or a GitHub Supportee link, I can't find it.)
I didn't push that commit to master since it would mess up the history, but you can find the version at npm.
I just pushed a v2.9.1
branch if you want to see the commit.
Success! Our builds are green again (Debian 9, Ubuntu 16.04, Ubuntu 18.04). Thank you!
I see that you now have 2.9.1 tagged as latest
on npm. I think that could be changed back to 3.0.0 without breaking anything, if you prefer.
Then again, it seems like the only difference between 3.0.0 and 2.9.1 is the version number, which confuses me a little – was there no API-breaking change after all? Not that it matters to me though, as I’m not using the Needle API, I’m just a down-down-downstream consumer.
would be nice if you could tag 3.0.0 as latest on npm, since my dependency management pesters me to downgrade to the latest version 2.9.1 now.
There doesn't seem a way to update the latest
tag, so I'll have to publish a new version (v3.0.1
). It's the exact same code, though, so it won't make much difference if you install v2.9.1
.
Actually, I just managed to update the latest
tag so it points to v3.0.0
.
I also just opened a page on buymeacoffee!
2.9.0, apparently due to #370, does not work on Node.js 8. This breaks my build on Debian 9 and Ubuntu 18.04.
If this was intentional, could the
engines
in package.json be updated and a major version bump be made?(I am not using Needle myself, it appears to be pulled in as a dependency of
sqlite3
→node-pre-gyp
.)