`webpack.config.js` affects the parser behavior?

[Anemone95]

Hi, here is the problem. If I have a ./dir/main.jsx file with content:

function f(e, t, n, o, eo, d, Xn, Wo, Qo, qo, No) {
    return function () {
        "use strict";
        var to = () => eo ? d().createElement(Xn, null,
            <script type="text/javascript">{`<h1>aa</h1>`}</script>) : null;
        const Ho = Wo ? setImmediate : Qo ? (Vo = `axios@${Math.random()}`, qo = [], No.addEventListener("message", ({source: e, data: t}) => {
        }, 1), e => {
        }) : e => setTimeout(e);
    }();
};

If I build a database for ./dir, I get the problem:

codeql database create --language=javascript codeql-database --source-root=./dir --overwrite

Initializing database at ...
[2025-02-02 17:30:48] [build-stderr] Only found JavaScript or TypeScript files that were empty or contained syntax errors.
...

But if I create a ./dir/webpack.config.js and the content is:

module.exports = {};

I won't face that issue.

So why that happened? Will CodeQL update its parser configuration by webpack.config.js?

Besides, the CodeQL version is 2.20.1.

[redsun82]

👋 @Anemone95

It seems like CodeQL is encountering an error parsing that specific source. You can find more information about it in the db/diagnostic/extractors/javascript/autobuilder-1.jsonl file. That information is also reported when running a codeql database analyze command on the extracted database. That shows our extractor gets confused at line 6, column 86, corresponding to the No.addEventListener line, reporting an Assigning to rvalue error.

Notice, that adding the webpack.config.js file does not avoid the above error, it only suppresses the generic log message about only finding source files with errors, which is the case just because now the extractor encountered the webpack.config.js file that could be extracted without errors. You will still find the error diagnostics about the main.jsx file.

This seems to me like a CodeQL bug that I will report to the team responsible for javascript analysis. I could reduce the issue to this snippet:

function foo() {
    let x = <div></div>;
    return true ? (null, null) : e => { };
}

Seems like a combination of using a JSX element followed by a ternary expression with both the comma operator and a function in its cases will confuse our parser.

[asgerf]

Hi @Anemone95. Thanks for the report. We've found the underlying issue in our parser and are working on fixing it.

[Anemone95]

Sounds great! Thank you for your help!

[asgerf]

Should be fixed as of #18658. Thanks again for the detailed bug report. Note that it will take about two weeks for this to make it into a release.