Regression in how "long" is imported breaks Cloud Functions for Firebase

[inlined]

Public issue for StackOverflow. I also noticed our integration tests failing.

It seems this is because @types/long uses export = syntax. You can usually get away with using a standard import when someone uses export =, but documentation is quite clear that you're supposed to use import = require() in these cases. If the moon is in the wrong phase, a traditional import breaks. This issue seems to be hitting Firebase customers.

[alexander-fenster]

Is it still the problem with the latest version of google-gax, v2.30.3, that pins @grpc/proto-loader to v0.6.9 and should use long v4, not v5?

[alexander-fenster]

Just to give you some details - google-gax does not use long directly, but needs its types for these proto .d.ts files, so we just have @types/long as a devDependency. That worked well with long v4. In long v5 they apparently publish their own types that have precedence over @types/long, so might cause problems if a dependency pulls long v5 in the tree. I pinned one of such dependencies (@grpc/proto-loader) so it should now pull long v4.

We are going to fix imports anyway, it's just a little bit more complicated than the PR you sent, because we need to fix all 100+ client libraries first, and update google-gax at the same time. We are on it.

[inlined]

This is fixed in recent versions.