question: it is not clear why @babel/runtime is included in the deps of 10-alpha

Two years ago in #397 babel-runtime has been removed by @zerkalica with a reason to reduce end user bundle size, but in august last year in #833 @babel/runtime has been re-added by @TrySound with a readded with the same reasoning of reducing end user bundle size.

I dont understand re-addition of it and I dont claim it is wrong. I perhaps need more details behind this reasoning and how that was meant to work.

[NeoLegends]

Two years ago in #397 babel-runtime has been removed by @zerkalica with a reason to reduce end user bundle size, but in august last year in #833 @babel/runtime has been re-added by @TrySound with a readded with the same reasoning of reducing end user bundle size.

To be fair, I think the reasons provided in #397 were unreasonable in the sense there must have been some issue with tree shaking. The author of the issue claimed that the full 34kb of core-js were imported into his bundle, but in that example only a few helpers / core-js functions were required. With proper tree-shaking applied, the size-penalty would have been much less than that.

After all, the imports from babel-runtime should not be any different than the one babel inlines into the source files (except for loose mode, obviously). This implies that there should, with proper tree shaking, never be a negative (with negative meaning a bigger bundle) difference when extracting helpers into babel-runtime.

I’m very much in favor of extracting the helpers to reduce duplication.

[TrySound]

@iamstarkov We do not add any polyfills. Current babel runtime allows to share helpers like _extends, _inheris, _createClass between many packages so they are not duplicated dozens of times in user bundle. These helpers also cherry-picked like @babel/runtime/esm/helpers/extends which prevents appearing unnecessary code in user bundles.