Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Cannot find module './zlib_bindings' #48

zxcabs opened this Issue · 20 comments

node v0.6.1
pdfkit v0.1.6


var pdf = require('pdfkit');

Error log:

Error: Cannot find module './zlib_bindings'
    at Function._resolveFilename (module.js:334:11)
    at Function._load (module.js:279:25)
    at Module.require (module.js:357:17)
    at require (module.js:368:17)
    at Object.<anonymous> (/home/user/share/test_pdfkit/node_modules/pdfkit/node_modules/flate/lib/zlib.js:1:80)
    at Module._compile (module.js:432:26)
    at Object..js (module.js:450:10)
    at Module.load (module.js:351:31)
    at Function._load (module.js:310:12)
    at Module.require (module.js:357:17)

Okay, I have this too. It's only happening since re-installing everything with node v0.6.1

I have found basically nothing else in my Googling so far, except that this zlib_bindings is perhaps not getting installed automatically by npm for some reason.

[EDIT:] I'm a dirty liar, it looks like this is incredibly relevant: #42


i'm getting the same error in version v0.6.2 any help?


I had the same problem and fixed.
Goto node_modules/pdfkit/node_modules/flate/ directory.
Copy the file zlib_bindings from build/Release directory to lib directory.



Thanks, it worked :)


Does anyone object if the next release only supports Node 0.6.x? I would like to switch to using the built in zlib bindings...


I don't object, but felt obligated to mention this.

My personal stumbling block is that I'm using this on heroku right now, which is still at node 0.4.7, but honestly that's starting to create a lot of problems a lot of places now, and I'd rather just figure out some way to move up to 0.6.x for everything.

Utilizing the built in bindings sounds like a good direction from my naive view ... ...


@devongovett: Yes, please move to 0.6 and fix this issue with zlib bindings


Alright... took a look at this today, but found out that the zlib bindings in Node 0.6 are all asynchronous and the module I was using before was synchronous. So I'm going to have to do a larger refactoring of the code to make it work if I'm to use the built in bindings. I'd like to do that, but I'm busy with lots of other things so I don't really know when I'll get to it. If you feel motivated please send me a pull request. Sorry about the wait.


A bit more accurate how-to version of jacksctsai's:

  • Goto node_modules/pdfkit/node_modules/flate/build/Release directory.
  • Copy the file zlib_bindings.node to ../../lib directory (lib directory of flate!).

Hi there. Thanks for the hard work on this great module. Are there any updates on this issue? The manual file copy works, but wondering if anyone is looking to tackle the proper fix.


So the proper fix for this will be a refactor of most of the codebase to be asynchronous rather than synchronous as Node 0.6's built in bindings are async. I have been meaning to do this for a while anyway for performance reasons, and this issue compounds the problem. I'll be working on PDFKit more over the next few weeks so expect a fix for this and other issues shortly!

Sorry about the wait, and if you think you can tackle any of the open issues here it would be greatly appreciated as I am only one person! :)


That's great news. Many thanks for your effort!


any way to get the workaround working on cloud9. (I can't see the zlib_bindings file there)


@jacksctsai thank you!


I had this issue and my app is running on heroku, I don't have access to the filesystem directly from command line and what I did is copy the file programmatically. I don't know if this is the best solution but at least it works and let me generate PDFs using pdfkit while I wait for a new pdfkit release.

var fs = require('fs');
var util = require('util');
var is = fs.createReadStream('./node_modules/pdfkit/node_modules/flate/build/Release/zlib_bindings.node')
var os = fs.createWriteStream('./node_modules/pdfkit/node_modules/flate/lib/zlib_bindings.node');
util.pump(is, os);

Why'd you close these issues they clearly aren't resolved?


Happens both on ubuntu and mac with node v0.6.11. Anoying when deploying! :/


Hello everyone! Finally getting a chance to work on this. I'd like opinions on whether you'd prefer to stick with the nice sync API that we have now or go completely async. This would mean that embedding images and fonts would become async operations and thus not chainable like everything else is. The reason for doing this would be so that we can switch to the built in zlib bindings that come with node 0.6, which unfortunately, are only available as async APIs.

The other option would be to stick with the sync API by using a zlib implementation entirely in JavaScript. Several of these already exist and would be fairly easy to implement. Performance would probably be slightly slower than using the native zlib bindings however. This would retain backwards compatibility with the current API and retain the nice sync style of the API as well as the internals.

In both cases we'd be getting rid of the silly flate module that has caused so much trouble especially on platforms not supported by node-waf like Windows. I'm super sorry it's taken me this long to get to it. But here we are! What do you think?


Great that you can look at this - thanks! I've a slight bias towards the async route, under the (perhaps misguided) impression that this will make the library more suitable (efficient) for deployment as some sort of web service.. If that makes sense then the trade-off for a more complex API (in parts) would be worth it. Is there a way of isolating the async calls in some sort of initialization step? Thereby leaving the rest of the API as is?


So this should finally be fixed now as of the above commit. Please let me know if you have any more issues.

The solution I came to was to use Node's built in zlib bindings, making some of the internals async. However, this should not affect the API for users much if at all. The only difference now is that the doc.output method is now asynchronous, meaning that you get a callback with the PDF data rather than having it returned to you. Otherwise the API is exactly the same as before. I did this by deferring all of the zlib stuff until the end when you ask for the generated document, keeping the API synchronous as before except for that one method.

Again, let me know if you have any more issues! Sorry it took so long for me to get to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.