Grpc-node: webpack error

[zknic]

vue.runtime.esm.js?2b0e:1737 TypeError: Cannot read property '_handle' of undefined
at eval (index.js?5fd0:3)
at Array.forEach ()
at module.exports (index.js?5fd0:2)
at Object.eval (log.js?6d4f:11)
at eval (log.js:311)
at Object../node_modules/grpc/node_modules/npmlog/log.js (6.js:696)
at __webpack_require__ (app.js:768)
at fn (app.js:131)
at Object.eval (napi.js?9018:5)
at eval (napi.js:205)

[murgatroid99]

I don't recognize that particular error, but in general you can't use grpc with webpack. The native addon does not work with webpack.

[lucas-rudd]

@murgatroid99 could you elaborate on that a little bit?

I'm having similar issues, but a different error.

My issue comes down to using the built in nodeJs require.resolve method in this line here

https://github.com/grpc/grpc-node/blob/master/packages/proto-loader/src/index.ts#L333

when running this through webpack, this fails to resolve a string value, and instead webpack resolves it to a numeric value.

At runtime, I then get the error

TypeError: Path must be a string. Received 124

This issue could be resolved by altering the require.resolve usage, replacing it with eval("require.resolve('protobufjs')")

[murgatroid99]

That proto-loader library is a different library, and it does not have the problem I was talking about. That being said, it was not written accounting for webpack. I am not really comfortable adding an eval call to the library just because webpack doesn't understand how to handle require.resolve, and I suspect that even with that change that code still won't function properly even with that change.

[kaisellgren]

@lucas-rudd I wrote a hack to fix that issue: https://github.com/grpc/grpc-node/issues/969#issuecomment-633271735

Is it really a good idea to synchronously load files when a module is merely imported? To me this seems rather smelly. Surely the consumers of the library can write one or two lines of code to invoke a function to do that if they need those proto files. Right now, just importing @google-cloud/storage crashes your entire production application, because this lib is executing code at the top-level and without anyone even asking for it. I have a feeling there's a better way to do this, but I will leave this at that.

[murgatroid99]

I see loading those files and generating code from them at import time as being no different from using require to load a JavaScript module at import time, which I think we would all agree is acceptable.

[kaisellgren]

I see loading those files and generating code from them at import time as being no different from using require to load a JavaScript module at import time, which I think we would all agree is acceptable.

Using the _de-facto_ and also the _most popular_ build tool in the JavaScript community to build this:

import gcs from '@google-cloud/storage'
console.log('hello')

Will result in the application _crashing_. And that's not even all of it: there's _no way_ to catch the exception and handle/ignore it. It doesn't seem very acceptable to me :P

I understand it's a combination of grpc code and Webpack. However, a million libraries work fine with Webpack. I'll just continue using my hack script for now and consider writing my own library for GCS.

[JustinBeckwith]

Greetings folks! If you're specifically having this problem with @google-cloud/storage, we'd love to help over here:

👉 https://github.com/googleapis/nodejs-storage/

That library shouldn't require @grpc/proto-loader at all, so something is wrong :)

[kaisellgren]

So, I did some digging. The @google-cloud/storage has a devDependency:

  "devDependencies": {
    "@grpc/proto-loader": "^0.5.1",

Which is not the problem. Turns out, the culprit was the @google-cloud/logging library, which specifies:

"dependencies": {
    "google-gax": "^1.11.0",

This google-gax library then specifies:

"dependencies": {
    "@grpc/grpc-js": "~1.0.3",
    "@grpc/proto-loader": "^0.5.1",

Which then causes the problem.

I found a way to fix this without any hacks.

For anyone having this problem in the future, add this to your Webpack build config:

externals: {
  '@grpc/proto-loader': 'commonjs @grpc/proto-loader',
},

Would it be possible to have a note about this in the README.md? That anyone using Webpack needs to manually specify this library as a commonjs external module. The original error message was: TypeError: Path must be a string. Received 124.

All good now, I'm out. Thanks for the help guys.

[JustinBeckwith]

Thanks for digging in! @murgatroid99 @bcoe @alexander-fenster any issues with transferring this over to https://github.com/googleapis/google-cloud-node/ so we can centrally deal with it there?

[alexander-fenster]

@kaisellgren One quick clarification here, which target are you using for webpack, is it target: 'node' or are you making a browser bundle?

@JustinBeckwith Agreed, google-cloud-node is a better place for this discussion.

[kaisellgren]

@alexander-fenster target is set to 'node'.

[murgatroid99]

I don't think this issue should be transferred. The issue is still mostly about packages in this repository.

[murgatroid99]

I am pretty sure I have fixed the proto-loader part of this issue in version 0.5.5.

Other than that, the gRPC implementation libraries themselves are not intended to function when webpacked.