export * from "foo";
console.log(val);
let val = 4;
export function foo() {
  console.log(val); 
should in theory end up as
System.register(["foo"], function (_export, _context) {
  "use strict";
  let val;
  function foo() {
    console.log(val);
  _export("foo", foo);
  return {
    setters: [function (_foo) {
      var _exportObj = {};
      for (var _key in _foo) {
        if (_key !== "default" && _key !== "__esModule") _exportObj[_key] = _foo[_key];
      _export(_exportObj);
    execute: function () {
      console.log(val);
      val = 4;
but then the TDZ behavior has to be lost.
You could imagine something like
System.register(["foo"], function* (_export, _context) {
  "use strict";
  _export(0, function (_foo) {
    var _exportObj = {};
    for (var _key in _foo) {
      if (_key !== "default" && _key !== "__esModule") _exportObj[_key] = _foo[_key];
    _export(_exportObj);
  _export("foo", foo);
  console.log(val);
  let val = 4;
  function foo() {
    console.log(val);
allowing preservation of module semantics much more accurately, which also allowing for easy yielding of promises for top-level await handling.
          
From a TDZ perspective also note that the format isn't designed to catch all invalid runtime scenarios (eg you can import named exports that don't exist). Rather it is designed to support the valid working runtime scenarios that work in ES modules, as a backwards compatibility workflow. So TDZ throwing being out of scope has kind of always been the assumption.
          
The vast majority of Babel users who use ES module syntax currently compile it down to CommonJS. If there's no reasonable compilation strategy for top-level await that targets CommonJS (and I don't see how there could be, given that CommonJS require implicitly mandates synchronous module execution), I strongly believe Babel should not bother compiling TLA syntax.
Bundling tools (which ultimately decide how the runtime module system is implemented, and whether it can handle async modules) can handle top-level await expressions however they choose. Babel should leave top-level await alone.
The very fact that you're talking about implementing TLA in a SystemJS-specific way highlights the folly of handling top-level await in Babel. In order to get this right, you need to know how your runtime module system works, and that has never been something that Babel could assume.
To put it another way, what if you're targeting Node? Does the generator function strategy make any sense in that context? If it only makes sense for SystemJS… well, then that's all we've accomplished. Babel as a whole should not advertise support for top-level await unless it has a strategy for every environment.
We don't even know whether top-level await will be restricted to modules without exports (the optional constraint) yet. Do we really want developers to start writing code that depends on an unfinished specification? Is that really a constraint on future TLA design that we're willing to accept?
Perhaps exported symbols could be proxies that will block when trying to get a value that is not available?
Proxies are another notoriously impossible-to-transpile ECMAScript feature, so I don't think this strategy makes sense for a transpiler like Babel.
          
I opened this issue back in January in hopes of sparking discussion about transpilation strategies for top-level await: tc39/proposal-top-level-await#2
In short, if we could agree on a general mechanism for defining asynchronous modules in ESM, without relying on top-level await as a primitive, then it would be dramatically easier for tools like Babel to compile top-level await down to something that works in all the major module runtimes.
          
I think supporting it SystemJS could be feasible since it's a bit more flexible format-wise, but otherwise I totally agree. I don't see how we could hope to handle top-level await with Babel's per-file approach to compilation, and I think it's reasonable to leave that responsibility to other tooling.
          
Some speculation:
The biggest use case (imo) for TLA is Node scripts and CLIs. (await import() is a distant second)
Node will probably ship TLA within the next year (@MylesBorins can correct me if I'm wrong)
Lots of people are already using async-await directly in Node, using it with Babel is actually kinda rare due to how difficult it is to setup today.
Most people will just use versions of Node that support TLAs if they want it.
As such, I don't really feel a big need for this feature to be supported. At least not enough that justifies complicating things a lot.
          
Stage 2 proposals should not be interpreted as stable. Decorators has changed significantly while at Stage 2, and other Stage 2 proposals have been dropped entirely (e.g., Object.observe). In my opinion, it's still valuable for Babel to implement early-stage proposals, to get feedback from JS developers and guide the proposals' evolution. I'd recommend that developers avoid proposals which are Stage 2 and below for code which needs to be maintained over time.
          
Can you speak to the specific complications?
None of those were brought up at the last meeting
We are continuing to work on the spec text and examining how inplementation
would work. Of people have concerns they should be opening issues on the
proposal.
On Sun, Jun 24, 2018, 12:10 PM John-David Dalton ***@***.***> wrote:
 Yep. That said though, Babel is an open source project with limited
 resources. Since this proposal currently has significant complications, and
 will likely require changing, their resources may be better spent on other
 proposals is all.
 You are receiving this because you were mentioned.
 Reply to this email directly, view it on GitHub
 <#44 (comment)>, or mute
 the thread
 <https://github.com/notifications/unsubscribe-auth/AAecV0AFAreBu_s9qU6h5vWu5TSNb871ks5t_7nzgaJpZM4UJRjP>
None of those were brought up at the last meeting
I believe some were unclear at the last meeting on exactly which parts were making it to stage 2 and how those parts affect modules and the ecosystem as a whole. Since the meeting, while working with Babel and the Node Module WG, concerns have been raised which will need to be addressed.
Of people have concerns they should be opening issues on the

proposal.
Yep, probably.
          
@littledan
I think it's worth it to get these things in Babel for early prototyping and feedback before Node would ship it, even if it might not be used so much in production.
I agree, but we have in the past decided not to support features in Babel because of the problems they can cause.
Example: Proxies could have been supported in Babel, but it would've required wrapping every get/set operation in your entire program including in code that might not be compiled by Babel or by the same version of Babel.
TLA is similar in that it requires wrapping every module in your program with something systemjs-y, even modules that aren't compiled by Babel or by the same version of Babel.
If you want to discuss the motivation of the feature, I'd recommend doing so in the proposal's repository.
I think the proposal is already well motivated, I'm very keen to use it. Just not via a Babel transform.
  tom-wang, seanlindo, liuliangsir, tscpp, ar2r13, Herz3h, and neelkarma reacted with laugh emoji
  ganapativs, marcofugaro, Mouvedia, lautarodragan, christian-schulze, ndabAP, kamthamc, zhaoyao91, resynth1943, paul-arthurthiery, and 11 more reacted with hooray emoji
  hax and liuliangsir reacted with confused emoji
  ndabAP, belozer, walleXD, 10thfloor, seanlindo, liuliangsir, ar2r13, and neelkarma reacted with rocket emoji
  zhaoyao91, liuliangsir, Herz3h, and neelkarma reacted with eyes emoji
    All reactions