Add @babel/runtime as a dependency to @wordpress/components

[gwwar]

Currently we publish a bundle that refers to @babel/runtime but does not require it as an explicit dependency in package.json. To not confuse consumers of this package, let's declare this dependency!

[gziolo]

Yeah, it wasn’t clear how we should approach it. It seems like the best way to go. I think we should do it for every package which transpiles code 😃

[mmtr]

Yeah, it wasn’t clear how we should approach it. It seems like the best way to go. I think we should do it for every package which transpiles code 😃

agreed! that will also fix #7936

[mmtr]

@gwwar @gziolo shouldn't we increase the package version?

[gwwar]

shouldn't we increase the package version?

@gziolo Does Lerna bump the package version, or would you like me to update it in package.json?

[gwwar]

I can make PRs for the other packages too, I wanted to see what folks thought first 👍

[gziolo]

No, Lerna takes care of it when doing publishing. It also creates git tags and temporary replaces all locally scoped packages with the proper published version in the dependencies list. Isn’t it sweet? 😃

[gwwar]

👍 Thanks for the reviews!

[gziolo]

I can make PRs for the other packages too, I wanted to see what folks thought first 👍

That would be ace, I would be able to publish updates tomorrow morning.

[blowery]

I think we should do it for every package which transpiles code

@gziolo At least anything using transform-runtime, yeah.

It looks like we're currently shipping polyfills in the packages. We may not want to do that long term. We're polluting the global prototypes for anything that uses these packages and polyfillng even in cases where the polyfill isn't needed.

Other projects (React, Draft, ...) are now stating what needs to be polyfilled up front and leaving it up to the client. That might be an approach to take?

[gziolo]

It looks like we're currently shipping polyfills in the packages. We may not want to do that long term. We're polluting the global prototypes for anything that uses these packages and polyfillng even in cases where the polyfill isn't needed.

Other projects (React, Draft, ...) are now stating what needs to be polyfilled up front and leaving it up to the client. That might be an approach to take?

Honestly speaking, we are learning the process ourselves. If you have exact recommendations on how to setup all that let us know. Excluding all the packages which aren't transpiled we ship 2 versions using the following Babel config:

1. build which contains code for the majority of browsers with modules set to commonjs and a new Babel 7 value for useBuiltIns option: usage.
2. build-module which differs only in a way that it generates ES Harmony modules (import & export).

The fact that we include import statements for both polyfills and Babel runtime comes from the new useBuiltIns setup. Now the questions is how would you see this improved to ensure that consumers can pick ES5 or ESNext version of the code depending on their needs.

/cc @youknowriad

[blowery]

Now the questions is how would you see this improved to ensure that consumers can pick ES5 or ESNext version of the code depending on their needs.

Clients won't generally ever want to consume es.next, it's just too difficult given current tooling. Some will want es5 wrapped in commonJS (package:main) and some will want es5 wrapped in es6 modules (package:module). Some folks are exposing the raw source under jsnext:main but it's not that common as you also have to expose your transpilation expectation in some fashion.

Whether or not you have polyfills in the es5 code is a separate issue. Libraries should not ship polyfills that affect the global scope. Instead you should use babel's transform-runtime to ponyfill usages that need back-compat, or ship the problematic usage and explicitly declare that clients must polyfill certain things it they want the code to work on older browsers. transform-runtime has the limitation that it cannot ponyfill usage of new properties on prototypes, so things like Array.prototype.find won't get fixed. If you go that route, you have to avoid usage (which we did on Calypso for a long time).

[gwwar]

@blowery do you mind opening up a new issue so folks can discuss transformation options for packages? It's a good discussion to have and I'm afraid your comment will be lost on this PR.

[gziolo]

We use transform-runtime when producing a distribution version of packages. See:
https://github.com/WordPress/gutenberg/blob/master/packages/babel-preset-default/index.js#L23

We also add @babel/runtime-corejs2 as a dependency of each package which is transpiled, e.g.:
https://github.com/WordPress/gutenberg/blob/master/packages/blocks/package.json#L23