Optimize computed properties output (byte-wise)

[Andarist]

Q	A
Fixed Issues?	n/a
Patch: Bug Fix?	no
Major: Breaking Change?	no
Minor: New Feature?	no
Tests Added + Pass?	Yes
Documentation PR	no
Any Dependency Changes?	no

It is a small "optimization" of the computed properties output. The change basically wraps (if possible) previous element - initProps object or previous defineProperty call when "pushing" new defineProperty calls.

It leverages the fact that defineProperty returns the passed object, therefore in most cases we do not need to create temporary references and stuff.

babel-plugin-transform-computed-properties/test/fixtures/spec/multiple illustrates this nicely.

Before

var _obj;
var obj = (_obj = {}, babelHelpers.defineProperty(_obj, "x" + foo, "heh"), babelHelpers.defineProperty(_obj, "y" + bar, "noo"), _obj);

After

var obj = babelHelpers.defineProperty(babelHelpers.defineProperty({}, "x" + foo, "heh"), "y" + bar, "noo");

Not only it saves some bytes in the output, it is probably more friendly for the minifiers too.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/55254/

[xtuc]

I don't understand how it worked before, either foo and bar were undefined in the score or you now re-define them?

[Andarist]

This was purely a fixture/snapshot test, I've added also exec.js and that's why I had to add those to the scope in actual/expected fixtures (like you have noticed - they were previously undefined).

[xtuc]

Ok that make sense

[xtuc]

@Andarist do we stil want this change?

[Andarist]

I would be in favour of merging this (after rebase ofc), but unfortunately noone (except you) has reviewed this.

[xtuc]

My review wasn't very useful, to push this forward we could discuss about it during our next meeting. Could you please add it to our agenda here babel/notes#73. thanks

[loganfsmyth]

Do you know what the actual byte difference ends up being once GZip is taken into account?

Is it worth exploring a new helper to optimize this instead? I don't know if that would be harder to keep the property evaluation ordering.

[loganfsmyth]

If we go with this, we should probably have a cap on the nesting here, or else we risk objects with lots of keys creating extremely deep AST structures.

[nicolo-ribaudo]

@JLHwung @liuxingbaoyu This is something that we can still do. I rebased this PR, and added a cap as suggested in #6652 (comment).

[Andarist]

Landing this PR was not my 2023 bingo card… 😝

[nicolo-ribaudo]

Life is full of surprises 😛