[bug][svelte/indent] invalid indentation in some specific scenarios inside <script>

[jamesst20]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.

What version of ESLint are you using?

9.4.0

What version of eslint-plugin-svelte are you using?

5.1.3

What did you do?

Configuration

import tsParser from "@typescript-eslint/parser";
import "eslint-plugin-only-warn";
import eslintPluginSvelte from "eslint-plugin-svelte";
import globals from "globals";
import svelteParser from "svelte-eslint-parser";

export default [
  {
    languageOptions: {
      globals: globals.browser,
      parser: tsParser,
    },
  },
  {
    files: ["**/*.svelte"],
    languageOptions: {
      ecmaVersion: 2022,
      parser: svelteParser,
      parserOptions: {
        extraFileExtensions: [".svelte"],
        parser: tsParser,
      },
      sourceType: "module",
    },
  },
  ...eslintPluginSvelte.configs["flat/recommended"],
  {
    files: ["**/*.svelte"],
    rules: {
      indent: "off",
      "svelte/indent": [
        "error",
        {
          alignAttributesVertically: false,
          ignoredNodes: [],
          indent: 2,
          switchCase: 1,
        },
      ],
    },
  },
  {
    ignores: [
      "postcss.config.cjs",
      "tailwind.config.js",
      "app/frontend/rails/",
      "node_modules/",
      "build/",
      ".svelte-kit/",
      "package/",
      "public/rcf-assets-dev/",
      "public/rcf-assets/",
      "tmp/",
      "coverage/",
    ],
  },
];

<script context="module" lang="ts">
  type GenericTypes = null | number | string | undefined;
  type GenericKeyType<Opt> = keyof Opt | never | null | undefined;
  type ValueType<Opt, VKey extends GenericKeyType<Opt>, VObj extends boolean> = Opt extends GenericTypes
    ? Opt
    : VKey extends keyof Opt
      ? VObj extends true
        ? Opt
        : Opt[VKey]
      : never;

  const dragDrop = (e: any) => {
    e.preventDefault();
    e.stopPropagation();
    /*
     * Warning: This event is called by the element the item was drop on top of.
     * Since we need to update the position of the dragged item (the source), we must use a
     * global context and the onEnd event.
     */
  };
</script>

What did you expect to happen?

Nothing the code is perfectly valid.

What actually happened?

Link to GitHub Repo with Minimal Reproducible Example

https://sveltejs.github.io/eslint-plugin-svelte/playground/#eJyNU01PwkAQ/SvjHgwQAonHAiVREg/G4MHgwXrY0mmpLrvN7pRIkP/uLKVVoCYmTTqzb96bN/uxE0uToAjE2C1tXhAsjSb8pEkk1iYpFUYClNQZ5+QiEUYagLYFwj1qtPnymWMHE9ClUvDFv3WMlgNHNtcZB6VOMM01JqNz6gNuPXs8LyhkhQ/cmhQ48TK4OagcVVs0FlKVWNP7sGAxYNuoE9emzxXz+L2piI1RKLVv6xueEQ8z+U4AU49XYXDapLFbob70pAXZEmvoRKfS4vTV673Vi0E1NE/oV/gUHIEza3xEWpmEjXYwAKm3XZiEsKtYOCgskzTNMJWlok53VAOOTPFkTSEzSbnRDTLsHRv24EVazWcUwK2S8eFroIuVoQ/2F+bmtEL74/C3tzyFTj1bpkws1czK7K66XYPUmjVcTY735vr670oy/6trFNskKlq39gaQMDwddNpl+q0a9Q7uD1sR6fGwejGh6AvLD8WJYCfcBhXhMOcLq0kEN/v9NwEAGd4=

Additional comments

No response

[ota-meshi]

I don't think the indentation of the ternary operator is a bug, but the rest of it might be.

[DollarAkshay]

I had the same problem today with a switch case.
It expected 16, I had 12.
After adding 4 more spaces, it said expecting 12 but found 16.

Adding "svelte/indent": [ error, { "indent": 4, "switchCase": 0 }] and setting the switchCase to 0 helped me fix this annoying issue.

[baseballyama]

I think this rule can be handled by Prettier, so it doesn’t need to be supported by ESLint.
I’d like to deprecate this rule in v3. What do you think? @ota-meshi

[ota-meshi]

In my opinion, support for stylistic rules is still needed.
Prettier is opinionated, so it might not be good for some projects.
ESLint is not a formatter, but the ESLint rule options are flexible, so I think the stylistic rules implemented in the ESLint plugin are still a good option for some projects.

[baseballyama]

We discussed this matter with the Svelte core team. Our general stance as maintainers is that we do not actively focus on fixing bugs or adding new features for formatting rules, but we are open to community contributions via PRs. Of course, if @ota-meshi feels it is necessary and wants to submit a PR, that’s perfectly fine. However, to ensure effective maintenance with our limited resources, we would like to lower its relative priority.

[ota-meshi]

we would like to lower its relative priority.

Yeah, I agree that fixing/adding stylistic rules is a low priority (unless someone in the community proactively works on it.)