Incompatible with Next.js / Webpack #2137
Labels
api: spanner
Issues related to the googleapis/nodejs-spanner API.
priority: p2
Moderately-important priority. Fix may not be included in next release.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Environment details
@google-cloud/spanner
version: 7.14.0Steps to reproduce
next dev
. Experience:Error: ENOENT: no such file or directory, open 'google/longrunning/operations.proto'
next build
andnext start
. Experience:TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type number (11363)
Analysis
The Node Spanner lib (this project), like some other Google libs using gax, require .proto files to be loaded from the package at runtime. This presents challenges for packaging solutions like webpack. If the first case above, webpack doesn't know that it needs to make the .proto files available in the final runtime files, which is why it doesn't package them and they can't be found. The solution to this is the explicitly copy the .proto files to an appropriate location in the webpack config, as follows (in next.config.js):
Once that is fixed, when doing build/start, the Spanner module code attempts to resolve the directory for the .proto files using require.resolve:
nodejs-spanner/src/common-grpc/service.ts
Line 46 in 1f06871
In webpack and similar environments, the behavior of require.resolve cannot be relied up to produce a valid path, and in the case of webpack, it doesn't produce a path (or even a string). In webpack, require.resolve produces a numeric module reference, which causes the above referenced code to fail and throw an exception, preventing the module from loading. The webpack workaround is as follows:
There are several issues open between Next.js and webpack in this area, but I don't get the impression either project sees it as their responsibility to address them. This same problem exists with other Google libs that use the grpc common code.
I don't necessarily expect that anyone is going to fix this on the Node Spanner side either. I'm opening this issue mainly because I blew about 12 hours digging into this and coming up with the above solution (finding no real credible/workable solutions when looking in the usual places based on the error messages I was seeing). I would expect the dev team will just close this, but at least future Next.js travellers may find it and save themselves some effort.
Here is the stack trace for the first issue (proto files not packaged):
And here's the stack trace for the second issue (require.resolve doesn't work as expected in webpack):
The text was updated successfully, but these errors were encountered: