fix: preventing infinite loops #1344

ota-meshi · 2025-09-10T01:35:38Z

No description provided.

changeset-bot · 2025-09-10T01:35:42Z

🦋 Changeset detected

Latest commit: 70bbe35

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
eslint-plugin-svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

github-actions · 2025-09-10T01:37:13Z

Try the Instant Preview in Online Playground

ESLint Online Playground

Install the Instant Preview to Your Local

npm i https://pkg.pr.new/eslint-plugin-svelte@70bbe35

Published Instant Preview Packages:

eslint-plugin-svelte: https://pkg.pr.new/eslint-plugin-svelte@70bbe35

View Commit

baseballyama · 2025-09-10T02:00:45Z

This is exactly the kind of implementation I had in mind for managing visited nodes.

marekdedic · 2025-09-10T12:35:32Z

Thanks for the quick PR. My thoughts comparing it to #1344:

This would be easier to understand than the ASTSearchHelper
If I understand it correctly, the new function would track all nodes visited from the calling function (hence why it's the first parameter)
- Do we need to clean up the set in order for it now to grow enormously on large codebases?
- What if we call findVariable from the same function multiple times?
The findVariable function is already re-implemented in this package, so maybe we wouldn't even need findVaraibleSafe and could just change findVariable? Then we also wouldn't need the internal rule.
In the previous PR, I was going for a more general pattern inspired by the ReferenceTracker from eslint-utils. I still think something like that would make sense, but I agree that it would be better to separate it from the findVariable recursion issue.
Is there any other way we could get an infinite loop? The previous PR was in that sense more general and would prevent recursion through any means. But I can't think of another way right now.

ota-meshi · 2025-09-10T13:27:57Z

At least nobody is opposed to this change, so I'll mark it as ready.

The findVariable function is already re-implemented in this package, so maybe we wouldn't even need findVaraibleSafe and could just change findVariable? Then we also wouldn't need the internal rule.

Yeah, I think it's worth considering. In this PR, I wanted to minimize the difference and check that it can be checked with an internal custom rule.

In the previous PR, I was going for a more general pattern inspired by the ReferenceTracker from eslint-utils. I still think something like that would make sense, but I agree that it would be better to separate it from the findVariable recursion issue.

In my experience, I don't think the internal implementation of ReferenceTracker is very common in normal rule implementations. In other words, I currently think that maintaining the current implementation method as much as possible will make it easier for people with experience with eslint-plugins other than eslint-plugin-svelte to follow.

Is there any other way we could get an infinite loop? The previous PR was in that sense more general and would prevent recursion through any means. But I can't think of another way right now.

In my experience, I've never seen an infinite recursion issue like this outside of identifier tracking.

This PR owes a lot to your PR #1338, which gave me a lot of inspiration. Thank you so much!

packages/eslint-plugin-svelte/internal-rules/prefer-find-variable-safe.ts

packages/eslint-plugin-svelte/src/utils/ast-utils.ts

packages/eslint-plugin-svelte/src/rules/no-dynamic-slot-name.ts

packages/eslint-plugin-svelte/src/rules/no-not-function-handler.ts

packages/eslint-plugin-svelte/src/utils/ast-utils.ts

marekdedic · 2025-09-10T15:11:04Z

packages/eslint-plugin-svelte/eslint.config.mjs

@@ -1,5 +1,12 @@
 import * as myPlugin from '@ota-meshi/eslint-plugin';
 import * as tseslint from 'typescript-eslint';
+import { createJiti } from 'jiti';


Is jiti really needed here? I don't understand this much, but why not just import the rule straight away?

The rule is implemented in Typescript, so we need to import them via jiti. This will no longer be necessary once we drop support for older Node.

marekdedic · 2025-09-10T15:12:53Z

packages/eslint-plugin-svelte/internal-rules/prefer-find-variable-safe.ts

+import type { TSESTree } from '@typescript-eslint/types';
+import type { Variable } from '@typescript-eslint/scope-manager';
+
+export default {


I'd still prefer just merging findVariableSafe into findVariable. Then the whole complication with this, and jiti can go away. And if I understand correctly, it's entirely possible, especially if we switch to marker: Symbol or marker: string.

I think it's redundant to have more arguments that we won't use.
So I think it's better to leave it as it is.

ota-meshi · 2025-09-11T01:01:26Z

When I was testing this, I found that the second lookup to the same identifier node (which is not recursive) returned null, which didn't work 😓
I'll think of a way to solve the problem.

ota-meshi · 2025-09-11T03:02:42Z

I've done a major rewrite to solve the problem.
It's now handled in a pretty basic way.
I think this is easier than having to pass around a set of identifiers.

baseballyama

Thank you!

marekdedic · 2025-09-14T08:52:50Z

Hi @ota-meshi , I just found out the internal rule doesn't trigger here, is that correct?

https://github.com/sveltejs/eslint-plugin-svelte/blob/main/packages%2Feslint-plugin-svelte%2Fsrc%2Frules%2Fno-navigation-without-resolve.ts#L134

ota-meshi · 2025-09-15T12:30:47Z

Yeah, if there is no recursion it will not be reported.

PoC: preventing infinite loops idea

c891a92

ota-meshi mentioned this pull request Sep 10, 2025

Preventing infinite loops #1338

Closed

ota-meshi marked this pull request as draft September 10, 2025 01:36

add internal eslint rule

88c4eaa

Create shy-countries-carry.md

1ea5b5e

ota-meshi marked this pull request as ready for review September 10, 2025 13:13

ota-meshi changed the title ~~PoC: preventing infinite loops idea~~ preventing infinite loops Sep 10, 2025

ota-meshi requested a review from baseballyama September 10, 2025 13:28

baseballyama reviewed Sep 10, 2025

View reviewed changes

packages/eslint-plugin-svelte/internal-rules/prefer-find-variable-safe.ts Show resolved Hide resolved

packages/eslint-plugin-svelte/src/utils/ast-utils.ts Outdated Show resolved Hide resolved

marekdedic suggested changes Sep 10, 2025

View reviewed changes

Replace with FindVariableContext

70bbe35

ota-meshi requested a review from baseballyama September 11, 2025 03:02

baseballyama approved these changes Sep 13, 2025

View reviewed changes

baseballyama changed the title ~~preventing infinite loops~~ fix: preventing infinite loops Sep 13, 2025

baseballyama merged commit 03a93f4 into main Sep 13, 2025
17 checks passed

baseballyama deleted the add-findVariableSafe-utlity branch September 13, 2025 01:19

baseballyama mentioned this pull request Sep 13, 2025

Infinite loop in consistent-selector-style #1337

Closed

2 tasks

This was referenced Sep 13, 2025

chore: release eslint-plugin-svelte #1357

Open

chore: release eslint-plugin-svelte marekdedic/eslint-plugin-svelte#3

Open

Uh oh!

fix: preventing infinite loops #1344

fix: preventing infinite loops #1344

Uh oh!

Conversation

ota-meshi commented Sep 10, 2025

Uh oh!

changeset-bot bot commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

github-actions bot commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Try the Instant Preview in Online Playground

Install the Instant Preview to Your Local

Published Instant Preview Packages:

Uh oh!

baseballyama commented Sep 10, 2025

Uh oh!

marekdedic commented Sep 10, 2025

Uh oh!

ota-meshi commented Sep 10, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

marekdedic Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

ota-meshi Sep 11, 2025

Choose a reason for hiding this comment

Uh oh!

marekdedic Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

ota-meshi Sep 11, 2025

Choose a reason for hiding this comment

Uh oh!

ota-meshi commented Sep 11, 2025

Uh oh!

ota-meshi commented Sep 11, 2025

Uh oh!

baseballyama left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

marekdedic commented Sep 14, 2025

Uh oh!

ota-meshi commented Sep 15, 2025

Uh oh!

Uh oh!

changeset-bot bot commented Sep 10, 2025 •

edited

Loading

github-actions bot commented Sep 10, 2025 •

edited

Loading