1

I'm using Babel targeting ES2020 and trying to figure out whether I can rely on Object.keys to enumerate keys in the order specified by ES2020.

I understand that:

But I can't figure out whether Babel will polyfill features that are implemented in ways that don't conform to the targeted standard.

If an older browser implements a feature in a way that doesn't conform to the targeted standard, will Babel polyfill it to ensure that its behavior is standard-compliant?

Thanks for reading!

Example

Firefox 4.0.1 implements Object.keys such that numeric keys are not always displayed before string keys as required in ES2020.

> var fruit = {"banana": 1, "apple": 2, "tomato": 3, 100: 4}
> Object.keys(fruit)
>>> ["banana", "apple", "tomato", "100"]

Firefox 88.0.1:

> var fruit = {"banana": 1, "apple": 2, "tomato": 3, 100: 4}
> Object.keys(fruit)
>>> Array(4) [ "100", "banana", "apple", "tomato" ]
Evan Johnston
  • 11
  • 2
  • can you give us an example which browser implements a feature in a non-standard way? – Sysix May 20 '21 at 19:31
  • 1
    Example added showing Firefox 4.0.1 implements Object.keys in a way that does not comply with ES2020. – Evan Johnston May 20 '21 at 19:56
  • Good code doesn't rely on the enumeration order of object properties anyway, so this would be a low-priority issue for babel. The order was only standardised to make the spec more deterministic and avoid incompatibilities between engines, not because code should make use of this. – Bergi May 20 '21 at 20:05
  • @Bergi: Sure, if enumeration order is important, it makes sense to default to a map rather than an object. However, in Typescript I've been unable to type a readonly map as thoroughly as I can an object. The compiler can't know at compile time which keys the map should have without an explicit check before each use. Because I can make objects both safer and more ergonomic than a map, I think it's worth using an object **if** I can guarantee that it will behave predictably. – Evan Johnston May 20 '21 at 21:43

0 Answers0