Other Literals use value as the property name.

As far as I understand, the idea here is to have it similar to RegExpLiteral where value might or might not be representable on the target runtime so another field is needed to represent the parsing result in these cases.

Actually, you were the one who suggested that in #169 (comment)

Ah, that's right, there's no "type" or anything distinguishing it from other Literals. Got it. Okay, what should the value of these nodes be? Currently bigints are not allowed in the value field.

You suggested to use a BigInt literal for value. For that we would need to amend the Literal interface (extend interface Literal { type: string | boolean | null | number | RegExp | bigint;) and add value: bigint to this interface, right?

Yep, that should do it.

I pushed it, but with property value, not type.

How about raw and cooked? (i.e.raw would be "12345n" and cooked would be 12345n (as a BigInt))?

Also, how would this be represented on platforms without BigInt support?

cooked only exists with template literals. raw is not part of the spec for (non-template) literals (see #14).

As for platforms without BigInt support, I've been asking this myself, too. Babylon doesn't emit the value, so I'm not aware of any precedents. I can think of a) emitting null b) casting to a regular number, which is lossy.

FYI “platforms without BigInt support” includes (and will include, for all eternity^{[citation needed]}) JSON.

You are right, just as regular expressions. There's a discussion in #64 about JSON.

I think emitting null if bigint is not in safe integer space makes sense and would be in line with regular expression literals.

Why safe integer space? Use a bigint if the platform supports it (regardless of magnitude), null otherwise.

I've made value: bigint | null for now, but I would still prefer to drop or phase out value as explained in #64 (comment).