Hey @liamcmitchell-sc! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

also hit this - just wanted to say great repro steps and workaround @liamcmitchell-sc 🙌

We will need a bugfix plugin so when bugfix: true is enabled (Babel 8 defaults), we only transpile class properties when

1. User code is affected by the specific browser bug
2. User targets to affected browser versions
   An example of bugfix plugin can be found in Implement @babel/plugin-bugfix-safari-id-destructuring-collision-in-function-expression #13842, where we workaround another JSC bug.

We will need a new test in compat-table, similar to compat-table/compat-table#1765 and implement such plugin.

Experiments on this bug

Another affected example

{
  let a = [];
  new class {
    c = a[(0)]; 
  }
}

This one runs without ReferenceError, but c is correctly initialized as 42, which should have been undefined:

let a = [42];
{
  let a = [];
  new class {
    c = a[(0)]; 
  }
}

and this works as expected

let a = [];
new class {
  c = a[(0)];
}

So the bug is that, when resolving referenced identifiers within field initializer (a under c = ...), Safari miscalculate the scope of such bindings to the upper level (if exists), if such referenced identifiers are seen outside of a parenthesized expression (i).

So we don't have to apply the bug fix when

1. the class is defined in top level (popular cases),
2. the field initializer does not contain parenthesized expressions (popular cases)

When bugfix: false is used, we will apply the complete class-properties transform on affected Safari versions.

@JLHwung

So we don't have to apply the bug fix when

1. the class is defined in top level (popular cases),

Do plugins know if compiled code is run at the top level or bundled into functions?

2. the field initializer does not contain parenthesized expressions (popular cases)

The parenthesized expressions in my case are produced by Webpack Terser after all Babel transformations. Without knowing what transforms will happen after Babel, the fix would have to trigger if any variable is referenced.

Do plugins know if compiled code is run at the top level or bundled into functions?

Good point, we should probably be more conservative and apply the fix even if the plugin is at the top level.

The parenthesized expressions in my case are produced by Webpack Terser after all Babel transformations

I'd consider this something to be fixed in terser, since it takes working code and produces non-working code. It's identical to how Terser has a safari10 option to avoid producing code that is buggy in Safari 10.

I propose to fix this bug by wrapping class fields initializers in an IIFE if they contain any reference to a variable defined in the parent scope, and that reference is not nested within another function:

let a = [];
{
  let b = [];
  new class {
    x = a[0];
    y = b[0];
    z = () => b[0];
  };
}

becomes

let a = [];
{
  let b = [];
  new class {
    x = a[0];
    y = (() => b[0])();
    z = () => b[0];
  };
}

I don't think we should explicitly check for parentheses, because they are hard to predict in a transform. In some cases they are explicit, while in other cases they are implicitly printed by the generator (for example, when printing a multiplication between a number and a sum). Also, even if the class field currently does not contain parentheses they could be easily introduced by new transforms that transform an expression nested within the class field value.

Also, we'll need tests to make sure that the bugfix plugin works with all our other class-related plugins.

Quick note to say that the WebKit bug has been fixed and no longer reproduces in Safari 16, but of course the issue still applies in Safari 15.

Just faced and fought this bug for 3 days. So it's not clear to me where should be fixed. In babel or in terser?

One important note for the workaround, if you start to use private methods you'll also need to include @babel/plugin-transform-private-methods. There seems to be a dependency where @babel/plugin-proposal-class-properties requires @babel/plugin-transform-private-methods. (This makes intuitive sense, we probably need to transform private methods if we're going to transform class properties.)

If you start to use private methods in an environment that doesn't transform them but have applied the workaround to include @babel/plugin-proposal-class-properties, you'll get an error like:

Class private methods are not enabled. Please add `@babel/plugin-transform-private-methods` to your configuration.

I would update the workaround to include both:

{
presets: [
  [
    '@babel/preset-env',
    {
      include: [
        // See https://github.com/babel/babel/issues/14289
        '@babel/plugin-proposal-class-properties',
        // Private methods cannot be used with the class properties transform, ensure they're transformed as well
        '@babel/plugin-transform-private-methods'
      ],
    },
  ]
],
}

This is easy to see in the REPL. The following fails without the additional transform, but is compiled correctly with both transforms:

class C {
  #privateProp;
  #method() {}
}

Faced similar issue for below code snippet in Safari < 16 with error - "Reference error: Cant find variable t".

var t, a;   

class l {
    static staticVar = null === (t = window.someVariable) || void 0 === t || null === (a = t.someRandomFn("abcd")) || void 0 === a ? void 0 : a.then((e=>e));
}

The variable t was defined externally and initialized within a static variable of the class. While initializing t, the static variable failed to resolve the lexical scope for t. This issue occurred intermittently, resulting in a "Reference error: Can't find variable t." It was resolved by adding the @babel/plugin-transform-class-properties plugin.

Seeking insights into the transient nature of this error. Any ideas on what might have caused this intermittent failure?