chore: improve lint setup

[mcmxcdev]

Pre-flight Checklist

Please ensure you've completed all of the following.

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.

Description of Change

• update eslint config to closely mirror the ones from ferdium-app
• add .eslintignore
• opt in to eslint reportUnusedDisableDirectives config option
• remove trailingComma: all from prettier config which is default in prettier v3
• autofix or disable a lot of lint issues throughout codebase
• add volta configuration to package.json to autoload correct node and pnpm versions
• upgrade all eslint and prettier related dependencies to latest
• update lint:fix npm script
• reformat touched files with prettier

[mcmxcdev]

The "Check Recipe Version Bump" CI step failed, but I don't think we should require a version bump for formatter or lint changes only which don't modify the business logic.

[vraravam]

The "Check Recipe Version Bump" CI step failed, but I don't think we should require a version bump for formatter or lint changes only which don't modify the business logic.

no - this is unfortunately required to force the upgrade on the clients' installation of Ferdium. Otherwise, the installed version will not know to upgrade the services. I would suggest that we do a minor version bump of each service (there's a lot of them!) - which I had done in my other PR #399 . Maybe, I can resurrect that branch and merge the appropriate changes for version bump and also missing injections of service.css?

[victorbnl]

I think their point was it’s useless to make Ferdium clients update the service after lint changes. At first sight, code style changes seem to be useful for developers but not users, so the latter can just stay on the unformatted version until the next logic change. But maybe there’s more to it I don’t know of and it is actually necessary.

[vraravam]

I think their point was it’s useless to make Ferdium clients update the service after lint changes. At first sight, code style changes seem to be useful for developers but not users, so the latter can just stay on the unformatted version until the next logic change. But maybe there’s more to it I don’t know of and it is actually necessary.

that could be true, but then there's no way to verify this during the pre-commit sequence. If a bug is being RCA'ed, the first thing we do is confirm that the user is on the latest version of the recipe. And if the versions mismatch, then debugging becomes muddled. Such nuanced demarcation can (imho) be simplified.

[vraravam]

@mcmxcdev - I have rebased your work in this PR into a branch (no PR raised) here: https://github.com/vraravam/ferdium-recipes/tree/improve-lint-setup-vijay

This should take care of the version bumps. The build is now passing locally. If you are ok, please merge my code into your PR and we can continue with further fixes

[mcmxcdev]

The build is now passing locally. If you are ok, please merge my code into your PR and we can continue with further fixes

I have merged your changes into this PR, but there are still recipes failing the version bump check. Personally, I agree with Victor here that this seems redundant to do for formatting-only changes.

UPDATE: It's tedious but I bumped up the remaining recipes, all green now.

[vraravam]

Thanks approved the PR, and its building and running locally as well. Shall we merge this for the next nightly?

[mcmxcdev]

Thanks approved the PR, and its building and running locally as well. Shall we merge this for the next nightly?

Yes, let's get it merged since I plan on delivering some more PRs and would like to avoid conflicts with existing changes.