ember-cli-babel

ember-cli-babel copied to clipboard

Goals:

Have babel report to us which files/modules depend on which polyfils, Babel may accomplish this by merely appending an import for the polyfil/dep the current module depends on. This would enable subsequent build-tooling to pull in only the polyfils that are needed, and isolate them to the module that explicitly depended on them.

This would help reduce the duplication caused by the small support algorithms currently inlined.

var _temporalAssertDefined = function (val, name, undef) { if (val === undef) { throw new ReferenceError(name + " is not defined - temporal dead zone"); } return true; };

var _temporalUndefined = {};

var _defineProperty = function (obj, key, value) { return Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); };

Example:

given

let b = Symbol('foo')
let a = {
  [b]() {

  }
}

I would love to see something like:

import _temporalAssertDefined, { _temporalUndefined } from 'babel/temporal-assert-defined';
import _defineProperty from 'babel/defineProperty'
import Symbol from 'babel/core-js/symbol' // or something

var b = _temporalUndefined;
var a = _temporalUndefined;

b = Symbol("foo");
a = _defineProperty({}, _temporalAssertDefined(b, "b", _temporalUndefined) && b, function () {});

Todo:

• [x] flesh this out more.

Questions:

• [ ] should babel report back what features the module needs?
• [x] should babel just drop an import and let the rest of the build system derive what is needed?
• [x] does each support algorithm now need to be in its own module (i think so)

cc @sebmck

@stefanpenner Have you seen the runtime? Since core-js is now modular it's totally within reason to abstract the helpers into individual modules too.

@sebmck yes, its pretty close. Awesome!

Our system parses the es2015 imports though, to decide what to include in the final build. Currently with module transpiling disabled, I am unsure how runtime will handle it. If it just inserted the appropriate es2015 import statements, that should handle our needs.

@stefanpenner Yup that's how it works internally. It just outputs an import and the modules transformer picks it up and turns it into the requires. Should already work and if not it'd require very minimal code change.

@stefanpenner Yup that's how it works internally. It just outputs an import and the modules transformer picks it up. Should already work and if not it'd require very minimal code changes.

awesome. I believe the last time I looked into this, it did not. So apparently I have not been keeping up with the changes. You are a worldwind of productivity :)

I'll try this setup out, and report back. I have additional ideas, i would love to layer on this runtime detection concept. I'll get them in writing shortly.

Yep, the import is getting lost somewhere. Should be trivial to include.

There we go.

import _babelHelpers from "babel-runtime/helpers";
import _core from "babel-runtime/core-js";
var b = _core.Symbol("foo");
var a = _babelHelpers.defineProperty({}, b, function () {});

Rad.

:+1: this is awesome

/cc @zloirock

Would it be possible to make the library functionality modular if it isn't already with the module changes you've been making?

I made the helpers modular.

script.js

class Foo extends Bar {}

CommonJS

$ babel --optional runtime script.js

"use strict";

var _classCallCheck = require("babel-runtime/helpers/class-call-check")["default"];

var _inherits = require("babel-runtime/helpers/inherits")["default"];

var Foo = (function (_Bar) {
  function Foo() {
    _classCallCheck(this, Foo);

    if (_Bar != null) {
      _Bar.apply(this, arguments);
    }
  }

  _inherits(Foo, _Bar);

  return Foo;
})(Bar);

ES6

$ babel --optional runtime --blacklist es6.modules script.js

"use strict";

import _classCallCheck from "babel-runtime/helpers/class-call-check";
import _inherits from "babel-runtime/helpers/inherits";

var Foo = (function (_Bar) {
  function Foo() {
    _classCallCheck(this, Foo);

    if (_Bar != null) {
      _Bar.apply(this, arguments);
    }
  }

  _inherits(Foo, _Bar);

  return Foo;
})(Bar);

@sebmck if I understand the question correctly, second example https://github.com/zloirock/core-js#commonjs . For prevent global namespace pollutons, require('core-js/as-library') should be called at first. Separation into modules and API is not fully finished.

@zloirock Yeah, should have reworded my question better sorry. I was asking if it was currently possible or will be in the future to do require("core-js/library/symbol") etc.

@sebmck Not sure about the same api: for example, what should be available on core-js/library/object/keys - ES5 shim for Object.keys or only ES6 shim for accepting primitives? core-js/library/array - all ES5, ES6 statics, ES6 prototype, ES7, core-js methods? All features now available by namespaces / modules names, for example:

require('core-js/as-library');
var Symbol = require('core-js/es6/symbol');
var from = require('core-js/es6/array/statics').from;
var includes = require('core-js/es7/proposals').Array.includes;

But api / modules structure isn't finished, possible conflicts, I think, I will change it to something like:

var Symbol = require('core-js/library/es6/symbol');
var from = require('core-js/library/es6/array/from');
var includes = require('core-js/library/es7/array/includes');

@zloirock Yup, that looks great. Exactly what I (and most likely @stefanpenner envisioned), awesome work!

(and most likely @stefanpenner envisioned), awesome work!

yes, this is exactly it. If babel can inject these imports we are golden.

@stefanpenner Once core-js/library is modular it'll be trivial.

FYI the prerequisite stuff for this has been done on the Babel side, anything else?

FYI the prerequisite stuff for this has been done on the Babel side, anything else?

nope, I don't believe so. We are working currently on the selective build functionality in ember-cli itself.

I suppose we can provide an interim solution in the short term.

I suppose we can provide an interim solution in the short term.

Would love an interim solution if that's possible. Doesn't need to be optimal, just want PhantomJS to pass my tests for now.

How is it going with this issue? Will the polyfill be enabled in the next ember-cli version (1.13.2)

How is it going with this issue? Will the polyfill be enabled in the next ember-cli version (1.13.2)

if you reinstall node_modules you will have a version that allows manual opt-in of the polyfil.

Note: It does not include dynamic inclusion + tree shaking, with is the long term goal of this issue.

What's here left to do?

Going to close this as polyfill support was removed in v8.