Optional chaining in import bombs plugin out

Given the following config (which is used as part of a larger shareable config that gets published to npm):

module.exports = {
    plugins: ['import'],
    settings: {
        'import/parsers': {
            espree: ['.js', '.jsx'],
        },
    },
    rules: {
        // static analysis
        'import/no-unresolved': 0,
        'import/named': 2,
        'import/default': 2,
        'import/namespace': 2,
        'import/no-restricted-paths': 0,
        'import/no-absolute-path': 2,
        'import/no-dynamic-require': 0,
        'import/no-internal-modules': 0,
        'import/no-webpack-loader-syntax': 2,
        'import/no-self-import': 2,
        'import/no-cycle': 0,
        'import/no-useless-path-segments': 2,
        'import/no-relative-parent-imports': 0,
        // helpful warnings
        'import/export': 2,
        'import/no-named-as-default': 2,
        'import/no-named-as-default-member': 2,
        'import/no-deprecated': 2,
        'import/no-extraneous-dependencies': 0,
        'import/no-mutable-exports': 2,
        'import/no-unused-modules': 2,
        // module systems
        'import/unambiguous': 0,
        'import/no-commonjs': 0,
        'import/no-amd': 2,
        'import/no-nodejs-modules': 0,
        // style guide
        'import/first': 2,
        'import/exports-last': 0,
        'import/no-duplicates': 2,
        'import/no-namespace': 0,
        'import/extensions': [
            2,
            {
                jpg: 'always',
                jpeg: 'always',
                js: 'never',
                json: 'always',
                png: 'always',
                scss: 'always',
                svg: 'always',
                webp: 'always',
            },
        ],
        'import/order': [
            2,
            {
                groups: [
                    'builtin',
                    'external',
                    'internal',
                    'parent',
                    'sibling',
                    'index',
                    'unknown',
                ],
                'newlines-between': 'never',
            },
        ],
        'import/newline-after-import': 2,
        'import/prefer-default-export': 0,
        'import/max-dependencies': 0,
        'import/no-unassigned-import': 0,
        'import/no-named-default': 2,
        'import/no-default-export': 0,
        'import/no-named-export': 0,
        'import/no-anonymous-default-export': 0,
        'import/group-exports': 0,
    },
};

When stuff-utils.js is imported into Foo.js (see internals below), you get multiple errors from seemingly unrelated rules.

Foo.js

import StuffUtils from './stuff-utils';

const Foo = () => {
    const onButtonClick = evt => {
        StuffUtils.doStuff();
    };

    return (
        <div className="Foo">
            <button onClick={onButtonClick}>Testing</button>
        </div>
    );
};

export default Foo;

stuff-utils.js

const StuffUtils = {
    doStuff(foo) {
        const bar = foo?.bar || 'bar';

        return bar;
    },
};

export default StuffUtils;

Reported errors:

/Users/mprzybylski/Work/fe-eslint-config/examples/Foo.js
  1:24  error  Parse errors in imported module './stuff-utils': Unexpected token . (3:25)  import/namespace
  1:24  error  Parse errors in imported module './stuff-utils': Unexpected token . (3:25)  import/no-deprecated
  1:24  error  Parse errors in imported module './stuff-utils': Unexpected token . (3:25)  import/default
  1:24  error  Parse errors in imported module './stuff-utils': Unexpected token . (3:25)  import/no-named-as-default
  1:24  error  Parse errors in imported module './stuff-utils': Unexpected token . (3:25)  import/no-named-as-default-member

Changing stuff-utils.js to the below, no errors are reported in the same setup/configuration:

const StuffUtils = {
    doStuff(foo) {
        const bar = foo.bar || 'bar';

        return bar;
    },
};

export default StuffUtils;

[reintroducing]

@ljharb you are absolutely correct, our ecmaVersion was set to 9 and bumping to 12 “fixes” this. thank you for the quick reply, much appreciated.

[reintroducing]

I’ve gone ahead and created a basic example showing this. I’ll open an issue in babel’s eslint parser repo as well, but just for transparency and if you’re curious, you can grab it as well.

npm i && npm run lint

eslint-issue.zip