v26.4.2 is treating any file including /regex/.test(arg) as a test file

[blaenk]

Updated to 26.4.2 through renovate bot and noticed my CI failed because this linter was running on non-test files.

I came across this issue #555 which explains that anything that uses jest testing functions is treated as a test file.

The non-test files in question are simply doing regex matching of the kind e.g. /regex/.test(arg), which I would expect to not trigger this heuristic to treat it as a test file.

I reverted to 26.3.0 for now without any other changes and it's working. Just wanted to give you a heads up.

Thanks for working on this linter!

[G-Rath]

anything that uses jest testing functions is treated as a test file.

That's not true - our "heuristics" (if you want to call it that) is "have we been told to lint this file?". It is up to you to configure ESLint to only run our rules on files that you expect to be considered part of your test suite.

Please see this section of the README for details on how to configure that.

[blaenk]

Thank you I'm not sure how I missed that in the readme the first time around. I guess something changed since 26.3.0 to make this apparent.

I've changed my eslint config to only run this on test files and everything appears to be working as expected on 26.4.2

[G-Rath]

26.4.0 significantly improved (again) on how we resolve Jest function calls to support aliased imports (e.g. import { it as testThis } from '@jest/globals').

So the cases that we should reporting within a file for most rules are now:

1. you're using something that is imported from @jest/globals
2. you're using a global whose name matches one of the jest globals
3. one of our rules is still using the old behaviour or there's a bug

Since 3 is very much possible, I'd be interested in some more details on what linting errors you were getting and on the contents of the files they were on, if you're able to share that.

[blaenk]

The only two linter errors I was getting were:

extension:   14:1   error    Do not export from a test file     jest/no-export
extension:   90:38  error    Title must be a string             jest/valid-title

All three of the affected files are ones that contain a /regex/.test(arg).

The jest/valid-title error points to the line containing the /regex/.test(arg) code and the jest/no-export error points to any exports that appear in the file.

Here's the entirety of one of the files:

jest-puppeteer.config.js

const jest_puppeteer_conf = {
  browserContext: "default",
  launch: {
    timeout: 30000,
    headless: true,
    product: "chrome",
    dumpio: false,
    args: ["--no-sandbox", "--disable-setuid-sandbox"],
  },
};

function isDebugMode() {
  return (
    typeof v8debug === "object" ||
    /--debug|--inspect/.test(process.execArgv.join(" "))
  );
}

if (process.env.DEBUG) {
  jest_puppeteer_conf.launch.headless = false; // for debug:  to see what the browser is displaying
  jest_puppeteer_conf.launch.slowMo = 50; // slow down by 250ms for each step
  jest_puppeteer_conf.launch.devtools = true; // This lets you debug code in the application code browser
  jest_puppeteer_conf.launch.args = ["--start-maximized"]; // maximise the screen
}

module.exports = jest_puppeteer_conf;

Here are excerpts from other two typescript files:

This one is a .tsx file:

  …

  if (error) {
    if (
      (typeof error == "string" || error instanceof String) &&
      /The user turned off browser signin/.test(error as string)
    ) {
      return <GmailFallback text="Sign In" />;
    } else {
      return <GmailFallback text="Error" />;
    }
  }

  …

This one is a .ts file:

  …

    if (!url.endsWith("/")) {
      url += "/";
    }

    if (!/\/problems\/[^/]+\/$/.test(url)) {
      continue;
    }

    const puzzle = puzzleCache.get(url);

  …

I realize that may be too little to be useful, but I figured I'd give what little I could. Sorry if that doesn't help.

[G-Rath]

Thanks for that - I'm not sure why those rules are triggering based on what you've shown me, as they don't contain globals or imports from @jest/globals.

I suspect we might be missing a check somewhere to make sure literals are not included, and it just happens to not cause an error.

I wonder if it'll happen on other literals e.g. 1.test(...)

[G-Rath]

@blaenk yup so this was a bug - I've got a fix lined up which should be out very shortly

[github-actions]

🎉 This issue has been resolved in version 26.4.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀