[Bug]: super() in class methods is not reported by @babel/eslint-parser

[ljharb]

💻

• Would you like to work on a fix?

How are you using Babel?

@babel/eslint-parser

Input code

        class Foo extends React.Component {
          contructor(props) {
            super(props);
            this.initialValues = {
              test: '',
            };
          }

          render = () => {
            return (
              <Component
                initialValues={this.props.initialValues || this.initialValues}
              >
                {formikProps => (
                  <Input {...formikProps} />
                )}
              </Component>
            );
          }
        }

Configuration file name

No response

Configuration

n/a

Current and expected behavior

I would expect a parse error, because super() is not valid except in constructor() {} and this is contructor() {}.

Environment

v7.16.0 of @babel/eslint-parser, eslint v8.1.10, node v17.0.1

Possible solution

Don't allow super() outside of a class constructor() {}

Additional context

Confusion over this led me to file eslint/eslint#15234, but eslint 8 is actually handling this correctly because of the typo.

related: typescript-eslint/typescript-eslint#4072

[JLHwung]

Babel with estree plugin already throws: https://astexplorer.net/#/gist/03f767f5dbe210bd68f53a0e841b7d35/453f531ef48973e6054e8ca3860479762c2b626b

and we don't have "contructor" in the codebase anyway, I guess there is nothing can be done on Babel's side?

[ljharb]

hmm, then why does the test case pass for me in eslint-plugin-react? it fails properly in eslint 8.

[ljharb]

In AST Explorer, when i select the babel eslint parser, as opposed to the babel parser, it does not throw.

[nicolo-ribaudo]

I don't know why, but it looks like this is intentional:

babel/eslint/babel-eslint-parser/src/worker/configuration.cjs

Line 31 in 5b29557

allowSuperOutsideMethod: true,

However, allowSuperOutsideMethod should probably be changed to behave as if the code was wrapper within class { constructor() { } }.

EDIT: It was introduced in babel/babel-eslint#215

[nicolo-ribaudo]

We should probably just align with the current ESLint 7 and 8 behavior, since that PR was to align with the old ESLint/espree version.

Or maybe @hzoo you remember more context, even if it was 6 years ago?

[nicolo-ribaudo]

Other context for a similar behavior: babel/babel-eslint#327.

Since it was enabled on purpose, making it opt-in is a breaking change.

[ljharb]

oof, ok - so how can i opt out of this behavior?

[nicolo-ribaudo]

In your eslint config:

parserOpts: {
  babelOptions: {
    allowReturnOutsideFunction: false,
    allowSuperOutsideMethod: false,
  }
}

[nicolo-ribaudo]

Actually, babel/babel-eslint#327 is opt-in and not by default, so it's different (I can't convince myself if this should be a patch release or a breaking change).

[nicolo-ribaudo]

Currently ESLint accepts this code (our allowReturnOutsideFunction):

return 2;

[ljharb]

allowReturnOutsideFunction is correct for CJS and transpiled ESM, but wildly incorrect for native ESM, so it seems like it should depend on the sourceType.

allowSuperOutsideMethod hasn't ever been correct, so i'm baffled why that'd ever be enabled.