Enable ESLint v9 rules and fix existing lint issues

[vitormattos]

The Dependabot PR #7876 updates @nextcloud/eslint-config from v8 to v9.

This update also brings ESLint 10 and many new lint rules. After applying the new configuration, LibreSign reports many lint problems in the existing code.

The goal of this issue is to review these problems, fix the code when the rule makes sense for LibreSign, and enable as many rules as possible instead of simply disabling them.

This work should be done on top of #7876.

The current list of pending rules is maintained in the libresign/disabled-during-migration section of eslint.config.mjs. Please use this file as the source of truth.

What to do

Work on one ESLint rule at a time.

For each rule:

1. Remove it from libresign/disabled-during-migration.
2. Run npm run lint.
3. Review all reported cases and understand what the rule is trying to improve.
4. Fix all cases in a way that makes sense for LibreSign.
5. Run related tests when the change can affect behavior.
6. Create one commit for that rule.

For example:

fix(lint): enable no-empty
fix(lint): enable vue/no-dupe-keys
fix(lint): enable @typescript-eslint/no-empty-object-type

Keeping one rule per commit is important because some rules can change many files and this makes the pull request easier to review and revert if needed.

Review automatic fixes

npm run lint:fix can be used as a starting point, but every generated change must be reviewed.

An automatic fix is not always the correct fix.

For example:

• Improve long or complex code instead of disabling a formatting rule.
• Write useful documentation when JSDoc is required instead of adding empty comments only to make ESLint pass.
• Replace deprecated APIs when a supported alternative exists.
• Investigate duplicated, unused or suspicious code instead of hiding the warning.
• Be careful with Vue events, slots, translation strings, API fields and backend payload names because changing them can affect behavior.

Prefer fixing the code instead of adding eslint-disable comments or disabling rules globally.

If a rule really does not make sense for LibreSign, it can stay disabled, but explain the reason in the pull request.

Also remove old eslint-disable comments that reference rules that no longer exist.

If enabling a rule reveals a real bug or a problem that should be handled separately, mention it clearly in the pull request.

Acceptance criteria

• The work is based on chore(deps-dev): bump @nextcloud/eslint-config from 8.4.2 to 9.0.1 #7876.
• All rules listed in libresign/disabled-during-migration are reviewed.
• As many rules as reasonably possible are enabled.
• Rules remain disabled only when there is a clear reason.
• Automatic fixes are manually reviewed.
• Fixes improve the code instead of only making ESLint pass.
• Changes that can affect behavior are covered by existing or updated tests when needed.
• Old eslint-disable comments for rules that no longer exist are removed.
• npm run lint passes.
• Each ESLint rule is handled in a separate commit.

Good first issue

This is a good opportunity to learn the LibreSign frontend code, Vue, TypeScript and the lint rules used in the Nextcloud ecosystem.

The work can be done rule by rule, which makes it easier to understand the code and review each change separately.

Some lint rules can also reveal real problems that were already hidden in the code, so this task is not only about formatting.

Additional context

• If you have questions, feel free to ask in this issue.
• Give a ⭐️ star to this repository if you find LibreSign useful and would like to support the project.
• You can also join our community: https://t.me/LibreSign

[lfals]

Working on this

[lfals]

A quick question, the description mentions #7876 ,should I assume it will be fixed and proceed based on that, or do you want to #7876 to be fixed before moving forward? @vitormattos

[vitormattos]

#7876 is the starting point for this work. You do not need to wait for it to be merged before starting.

I made a quick check of the changes needed for the ESLint v9 migration, and there are many issues to fix.

The Talk app used a temporary disabled-during-migration section for some rules:
https://github.com/nextcloud/spreed/blob/main/eslint.config.mjs#L41-L61

I think we may need a similar approach for LibreSign, because fixing every rule in the same PR can become too large.

However, I also don't want to disable rules without reviewing them. The idea is to check them one by one:

• fix the rule when the changes are reasonable and safe. Please avoid creating a very large PR. If needed and possible, some lint fixes can be split into separate PRs;
• keep it temporarily disabled when fixing it would create a very large or risky change;
• explain why a rule needs to stay disabled.

The goal is to enable as many useful rules as possible. If some rules still need larger refactors, we can create follow-up issues for them.