Related to eslint/eslint#19134

I downgraded my project to eslint v9.14.0 and the crash is gone. Seems to be a regression in eslint itself.

It looks like @typescript-eslint/no-unused-expressions uses eslint's original no-unused-expressions, calling its create function, passing in the context. no-unused-expressions appears to be expecting context.options to be defined (as an array of options), as explained here: https://eslint.org/docs/latest/extend/custom-rules#the-context-object

https://github.com/eslint/eslint/blob/main/lib/rules/no-unused-expressions.js#L79

for some reason, @typescript-eslint/no-unused-expressions's create function appears to be receiving these options as a second parameter:
https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/rules/no-unused-expressions.ts#L36

not sure if this inconsistency was always there, but typescript-eslint may want to propagate options in?

Uh oh! @AviVahl, the image you shared is missing helpful alt text. Check #10338 (comment).

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

🤖 Beep boop! This comment was added automatically by github/accessibility-alt-text-bot.

the crash is due to this change https://github.com/eslint/eslint/pull/17656/files#diff-b65ad05fc10a27a62ba130f4ec20fce33dfdfed6917e58581c91d59067aeb30b

which makes typescript-eslint's way of using it break.
the fix should probably come in typescript-eslint, to match the rule's new context expectations.

Yes, as several have noted this is due to the @typescript-eslint/no-unused-expressions extension rule using brittle monkey-patching to compose our logic with that of the the base rule. When the base rule changes, so must our monkey-patch! I note that eslint/eslint#17656 seems to much broader than just affecting no-unused-expressions, so I honestly wouldn't be surprised if other rules are broken with eslint v9.15.0 too for the same reason. Worth looking into.

search for baseRule.create in the rules directory. I assume all these could break in theory. not sure which ones are included in the recommended preset.

perhaps the fix should be to match the new upstream defaultOptions behavior, and even use it for typescript-eslint rules via context.options (instead of second parameter)?

... I note that eslint/eslint#17656 seems to much broader than just affecting no-unused-expressions, so I honestly wouldn't be surprised if other rules are broken with eslint v9.15.0 too for the same reason. Worth looking into.

I originally hit this bug with typescript-eslint/no-empty-function. It was only after completely turning off that rule, I found the rule in this issue. Which then searching online found this GitHub issue. So yes, there are other rules that are affected.

perhaps the fix should be to match the new upstream defaultOptions behavior, and even use it for typescript-eslint rules via context.options (instead of second parameter)?

The thing to keep in mind is that we'll want to stay backwards compatible with eslint versions before 9.15. See also #6456.

If you end up poking around with this and find a good solution, do feel free to raise a PR 🙂

Considered it, but it seems like a wider change, so I'm hesitant given my limited knowledge of this codebase...

Considered it, but it seems like a wider change, so I'm hesitant given my limited knowledge of this codebase...

Totally fair! Rest assured that the root cause of this type of bug is very well understood by each of the maintenance team members, and will be addressed as soon as our bandwidth permits, unless a community champion is able to get to it first 🙂

First time looking into typescript-eslint code, but it seems to me that we should modify this section:

To include defaultOptions within the meta object. The updated code could look something like this:

    return createRule<Options, MessageIds, PluginDocs>({
      meta: {
        ...meta,
        defaultOptions: rule.defaultOptions,
        docs: {
          ...meta.docs,
          url: urlCreator(name),
        },
      },
      ...rule,
    });

You can extract defaultOptions directly in:
https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/utils/src/eslint-utils/RuleCreator.ts#L63-L67

The reason for this change is the introduction of the following update in ESLint:
https://github.com/eslint/eslint/blob/main/docs/src/extend/custom-rules.md#option-defaults

In PR:
https://github.com/eslint/eslint/pull/17656/files#diff-dc3f44ef800795b890a57c8dd95c6ce26ba8a47a4551d7a05d7a5cd9cf016597R805-R834

We should also update the defaultOptions in each rule to maintain parity, but so far this "quick" fix should be enough for now. (Note: I might be overlooking something since, as I mentioned, this is my first time looking into the code.)

I’d work on a PR for this, but I really need to get some sleep.

for some reason, @typescript-eslint/no-unused-expressions's create function appears to be receiving these options as a second parameter:
not sure if this inconsistency was always there...

@AviVahl our utilities have always supported a top-level defaultOptions property for as long as they have existed!
Our API design was to pass the merged options as a second parameter to the create function rather than changing the options on the context object because it allowed greater flexibility -- it gives you the option to see BOTH the user's actual config and the merged config -- which can sometimes be useful if you want to act differently when a user skipped an option but also avoid having undefineds around the place.

Unfortunately ESLint core chose a different location for the defaultOptions property just added in v9.15.0:

• It was added to meta.defaultOptions rather than as a top-level property, and
• They chose to overwrite the context.options rather than pass it as a separate argument.

In the next major we'll likely converge on their solution to deduplicate things.

@glass-ships Smells like a breaking change sneaking its way into a minor update. I've already locked all of my projects to v9.14.0 so I should be fine for now. I might look into it and see if I can craft a fix this weekend.

If I can figure out the codebase in just a weekend, that is... I don't have high hopes, but I feel invested in this considering how I found it just an hour after v9.15.0 came out, after doing my routine pnpm update 😬

Agreed! If you do happen to give this a shot, feel free to link me to your PR, I'd be happy to contribute however I can.

This is the eslint patch I used to get it working with typescript-eslint and unicorn

diff --git a/lib/rules/no-unused-expressions.js b/lib/rules/no-unused-expressions.js
index fd1437c1606a56cbce147d040d601d0acef3d24a..1ac2d6e45fbb04f93d9cccdc5265bb38c3701aca 100644
--- a/lib/rules/no-unused-expressions.js
+++ b/lib/rules/no-unused-expressions.js
@@ -76,7 +76,7 @@ module.exports = {
             allowTernary,
             allowTaggedTemplates,
             enforceForJSX
-        }] = context.options;
+        } = {}] = context.options;
 
         /**
          * Has AST suggesting a directive.
diff --git a/lib/rules/no-warning-comments.js b/lib/rules/no-warning-comments.js
index 628f5a2ac513303cc3fe2cc9adcbf1ae54128747..a42e8318e028c6a3717afceef3c949bf8eab5827 100644
--- a/lib/rules/no-warning-comments.js
+++ b/lib/rules/no-warning-comments.js
@@ -64,7 +64,7 @@ module.exports = {
 
     create(context) {
         const sourceCode = context.sourceCode;
-        const [{ decoration, location, terms: warningTerms }] = context.options;
+        const [{ decoration, location, terms: warningTerms } = this.meta.defaultOptions[0]] = context.options;
         const escapedDecoration = escapeRegExp(decoration ? decoration.join("") : "");
         const selfConfigRegEx = /\bno-warning-comments\b/u;

I had the same problem with V10.8.2 . it stopped happening if I downgraded the version to v9.14.0.

The issue is known. The fix is in progress.
Locking to avoid further noise.

Please subscribe to this issue to keep updated.

The fix has merged and will soon be released to our canary tag.
The fix will release to latest with our next release in a few days.
https://typescript-eslint.io/users/releases

Hello, I just installed canary and the error is still there.

Hello, I just installed canary and the error is still there.

Can you provide details and/or a reproduction?

If you think this isn't fixed, please file a new issue and provide a complete reproduction and we can investigate.

Update: The fix is now live in our 8.15.0 release! 🎉

If you encounter issues when you try it out, please double-check that each of the @typescript-eslint/* packages you're using is up-to-date (the most relevant one is @typescript-eslint/eslint-plugin), and create a minimal reproduction of the issue, before filing a new issue.