Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
71 lines (62 sloc) 3.68 KB

04/09

https://github.com/babel/notes/issues/90

Attending

  • Nicolò
  • Henry
  • Daniel
  • Denis

Google Season of Docs

  • Deadline is on the 04/23
  • If we want to apply, we first need to decide what we want docs for.
  • We might not needed it: it's nice that people writing docs are paid but it could be easier to just ask for help (e.g. on Twitter)
    • Docs on usage
    • Docs on making a plugin (although our API is large don't need to doc)

export changes in scope PR break meteor (issue)

  • We have always added early errors in minor/patch versions: being more compliant to the spec is an improvement, not a regression.
  • Throwing on undeclared exports disallows some valid usecases, like templates:
    const createExport = template.statement({ sourceType: "module" })`
      export { LOCAL as NAME }
    `;
  • We could jist remove the check and publish a new patch release?
    • If we decide that it is a regression, we could make it opt-in: validateExports
  • We already have some options to disable some context-depending errors: allowAwaitOutsideFunction, allowReturnOutsideFunction, allowSuperOutsideMethod. We could add an allowUndeclaredExports option.
  • A more general approach: we can add a "loose mode" to @babel/parser which shallows every early error.
    • Some early error also make sense in template contexts, like foo() = 2 or { __proto__: a, __proto__: b }.
    • It would be also useful for tools. babel-eslint could warn about every error instead of exiting on the first one, and prettier could format syntactically valid files with early errors.
    • We could both do this and the allowUndeclaredExports, they are not mutually exclusive.
  • TODO: Ask @benjamn how Meteor is using exports

@babel/parser refactoring from class to functions

  • Better performance, but only ~10%
    • I (Nicolò) don't know if 10% is "pretty good" or "normal improvement"
  • The output code, whem minified, is a lot smaller because function names can be managled, while method names can't.
  • Still plugin-based for now.
  • It needs a small wrapper around rollup/Babel, so it now has a custom build step
    • I (Nicolò) don't know if the performance improvement is worth it?
  • Nicolò will open a PR in the next few days so that we can discuss about it.
  • It will have conflict with every other PR modifying the parser.

Fix babel helpers to not require Symbol to exist (PR)

  • Current situation:
    • The _iterableToArray expects Map and Set to be iterable, so Symbol.iterator in obj should just work.
    • Map and Set provided by es6-shim are not iterable and can't be determined by Object.prototype.toString
  • We can't check obj instanceof Map and obj instanceof Set because @babel/runtime and @babel/preset-env will load the polyfills for them, which is very big.
  • We can't prevent @babel/runtime and @babel/preset-env from loading polyfills for instanceof Map and typeof Map, since it will break some valid usecases:
    if (typeof Symbol !== "function") {
      throw new TypeError("Required an engine with Symbol support");
    }
  • We could add a directive to disable polyfills for a specific expression:
    if (
      typeof /* no-polyfill */ Map === "function" &&
      obj instanceof /* no-polyfill */ Map
    ) {
      // is iterable
    }

@babel/polyfill

  • We decided to deprecate it for v7.4.0, but gave the community some time to migrate to direct imports of core-js.
  • core-js@2 will only receive critical bug fixes (e.g. security, regressions?), not any else.
  • It's time to npm deprecate it. Next patch? Or next minor?
You can’t perform that action at this time.