rules_typescript_proto
rules_typescript_proto copied to clipboard
Webpack support - Cannot find module 'google-protobuf'
Description
Hi @Dig-Doug. When loading my TS web app (which makes use of protobuf files and is built by Bazel + Webpack) I keep getting the following error:
Uncaught Error: Cannot find module 'google-protobuf'
which comes from var jspb = require('google-protobuf');
from the auto-generated ${NAME}_pb.js
file.
It seems the google-protobuf
library needs to be included at runtime (which is also mentioned here in the README). Can this even be achieved using Webpack? If so, why isn't Webpack itself resolving the dependency and including it in the bundle? What am I missing?
It seems you wrap UMD headers to those generated files here: https://github.com/Dig-Doug/rules_typescript_proto/blob/96a4ae2ad0eb9770e9d71ae29d34d5b871719a96/src/change_import_style.ts#L38-L53 — what's the reason for that?
Thanks for helping.
Your Environment
What operating system are you using?
Linux ubuntu1910.localdomain 5.8.0-25-generic #26-Ubuntu SMP Thu Oct 15 10:30:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
What version of bazel are you using?
Build label: 4.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Jan 21 07:33:24 2021 (1611214404)
Build timestamp: 1611214404
Build timestamp as int: 1611214404
What version of the library are you using?
sha256 = "aac6dec2c8d55da2b2c2689b7a2afe44b691555cab32e2eaa2bdd29627d950e9"
Hi @jozsbs,
Unfortunately I'm not familiar with webpack so I don't know why it's not resolving the dependency. We have an example of using rollup here which is able to include the library in the final bundle.
We UMD because UMD modules can be loaded in both browser and server environments, while other import styles cannot.
Hi.
I'm not sure if you are still looking for a solution, but I solved this by using umd-compat-loader
.
Another solution would be to use .mjs
output. However, it seems .mjs
is currently (at least partially) unusable due to #64. If you don't need GRPC bits, I guess this'd be a better solution.