I noticed that using env preset Babel turns all instances of undefined into void 0.
Arguments in favour of void 0 are mainly void (pun intended):
Allegedly it safeguards undefined from reassigning. This is not relevant now since ES5 spec was released a decade ago which prohibits that. Since then, you can't reassign undefined primitive.
Allegedly it takes less space than undefined. Three characters less. But minifying is not the purpose of Babel, is it?
Arguments against void 0:
void is operator, undefined is primitive type. By definition, primitive type is more efficient to process than operator whose result is the same primitive type. The difference might be negligible but I haven't seen void 0 vs undefined perf tests proving that.
ESLint flags upvoid 0 as a code bug, which means if you review Babel CommonJS build file (coming from Rollup typically), you'll see linting errors everywhere where you previously used undefined
For JS newcomers void 0 is an unnecessary burden to learn and obfuscated Babel builds make it more difficult to understand what Babel does.
I know, this is not a bug per se or a feature per se, but nonetheless it's an important, fundamental issue that needs to be looked at. I see no reason why we should transpile down to ES3 JS spec (because, technically, that's what we're doing at the moment).
Fun fact. early on you used to be able to redefine the undefined keyword in ES5, e.g.
so Babel, would convert any
undefineds it found tovoid 0More on that here
I noticed that using
envpreset Babel turns all instances ofundefinedintovoid 0.Arguments in favour of
void 0are mainly void (pun intended):undefinedfrom reassigning. This is not relevant now since ES5 spec was released a decade ago which prohibits that. Since then, you can't reassignundefinedprimitive.undefined. Three characters less. But minifying is not the purpose of Babel, is it?Arguments against
void 0:voidis operator,undefinedis primitive type. By definition, primitive type is more efficient to process than operator whose result is the same primitive type. The difference might be negligible but I haven't seenvoid 0vsundefinedperf tests proving that.void 0as a code bug, which means if you review Babel CommonJS build file (coming from Rollup typically), you'll see linting errors everywhere where you previously usedundefinedvoid 0is an unnecessary burden to learn and obfuscated Babel builds make it more difficult to understand what Babel does.I know, this is not a bug per se or a feature per se, but nonetheless it's an important, fundamental issue that needs to be looked at. I see no reason why we should transpile down to ES3 JS spec (because, technically, that's what we're doing at the moment).
Thank you.
and here's the a plugin in regards to this as well.
babeljs.io/docs/en/babel-plugin-tr...