Upgrade to long 5.0.0 for ESM support

[stephenh]

In theory some of our import hacks can go away now? Probably needs to be a breaking change for ts-proto as well.

[badeAdebayo]

when do you plan to update?

[stephenh]

@badeAdebayo I'm not personally planning on working on this soon; PR's would be great if you're interested!

[gotjoshua]

i am running into an issue importing ts-proto files into an oclif command, and i think this would fix it.
even with esModuleInterop: true i get:

This module can only be referenced with ECMAScript imports/exports by 
turning on the 'esModuleInterop' flag and referencing its default export.

3 import * as Long from 'long';

search and replace
import * as Long from 'long';
with
import Long from 'long';

gets it working (but not sure if that will break something else)
would it break some functionality in ts-proto to import in this way instead?

in the meantime is there a way to avoid this?

[alexisvisco]

Same issue here

[Tera]

same issue

[AnotiaWang]

Same issue

[Eashiong]

With --ts_proto_opt=esModuleInterop=true changes output to be esModuleInterop compliant.

Specifically the Long imports will be generated as import Long from 'long' instead of import * as Long from 'long'.

[stephenh]

I've merged #882 that:

a) upgrades ts-proto's internal usages of long (for reading protobuf descriptors) to long v5
b) changes the non-esModuleInterop to use the import Long = require("long") syntax, which I believe is the more correct way of importing long when not using esModuleInterop.

But, as @Eashiong as noted, if you're using esModuleInterop in your tsconfig.json, which I believe most projects do these days, then using esModuleInterop=true as the ts-proto opt is a good idea anyway.

We should probably make esModuleInterop=true the default at some point, but either way closing this issue as resolved.