Skip to content
Branch: master
Find file Copy path
Find file Copy path
@hzoo hzoo Update 58b3d37 May 22, 2019
1 contributor

Users who have contributed to this file

48 lines (35 sloc) 3.29 KB


Attending (team)


Some of us (Sven, Logan, Nicolò, Henry) will be at JSConf EU/TC39 in a few weeks and will be meeting each other for the first time in-person! Come say hi 👋! (and Henry with be at GitHub Satellite/Maintainerati as well)


  • What to do with the TS namespaces PR

    • (10 👍)
    • When TS team initially implemented the TS plugin, the thought was that since namespaces were not being recommended for use, it would not be a big loss if we didn't have support
    • Officially, there is no intention to deprecate namespaces (TypeScript#30994)
    • Of course a PR from the community would always be appreciated and now we have one!
    • Conclusion: To be safe (and per PR author), we're going to release this under a flag (allowNamespaces) until it's deemed ready. We plan on enabling this feature by default in a future release.


    • Ensure we are throwing good/helpful errors when a user encounters an unsupported case
    • Need to update documentation around caveats
  • Add an option to ignore uninitialized properties, to match Flow's and TS's behaviors

    • (8 👍)
    • Flow/TS doesn't follow the exact spec regarding a non-initialized class A { a; }.
    • Neither team has come to a decision around what they want to do
    • Babel 7 enabled features to be spec by default, including this behavior of initializing class fields.
    • Conclusion: Now we are just adding the option of making this compatible with TS/Flow behavior. -- We could also just make this default but not sure about this, as we have made most things spec compliant by default (although we certainly understand the issues with it requiring more config options and code size).


  • How do we want to apply for the Chrome Web Framework & Tools Performance Fund?
    • Form:
    • Ideas:
      • Could do more thinking around Babel helpers/runtime/transform-runtime, and research how it might work better with bundlers (webpack/babel-loader).
      • Other parser optimizations like with parsing TS? Appreciated but doesn't seem to be the kind of performance work they are looking for. Not build tool speed but output size and runtime speed.
      • Proposal by @nicolo-ribaudo: "Rethink polyfilling story"
    • Babel's contribution to code size is from: Input/Output code, helpers, polyfills. Make a tool that recommends config options for perf based on the output of their code/site.
    • Conclusion: Can work on better polyfilling (better version of useBuiltIns) Covers a wide range since almost all sites use polyfills and it covers more than just @babel/polyfill.
You can’t perform that action at this time.