chore: add ESLint setup

[nschonni]

Description

Generated the config and ignored the one use that was still flagged inline.

Motivation and Context

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[MikeMcC399]

BTW: Whilst I was looking for a replacement for eclint, I also set up a full ESLint example. I just rebased that and pushed to https://github.com/MikeMcC399/docker-node/tree/migrate/eslint for comparison.

I don't want to suggest this alternative for a PR or merge, since I think the current setup is good enough as it is. It is just a Proof of Concept development to share with you.

I'm OK with adding your PR which just does a base ESLint JS linting without additional plugins like stylistic.

Prettier and @stylistic/eslint-plugin disagree about formatting, so it's not practical to use both on the same files.

[MikeMcC399]

It would be more consistent to call these

lint:eslint
lint:eslint:fix

https://prettier.io/docs/comparison makes the distinction between formatters and linters

I am not hung up on the naming though. Anything that works, and is documented correctly is fine with me.

[nschonni]

I can change the name. The reason I tend to avoid tool names in the targets, is that you can/do change them overtime, so keeping them about the purpose reduces noise in the repos. EX: .github/eslint.yml needs to be renamed if you change tools, but if you change the tool inside a call target in the package.json, nothing else changes. The git file history also remains

[MikeMcC399]

In the case of ESLint, it could be extended to cover other types of files, like json, so then javascript wouldn't be right either.

Perhaps at some later stage the GitHub action workflows could be consolidated so they're not named after the individual tools, but instead after the purpose. I would however give this much lower priority than solving the automation issue to produce the releases, and preparing for the other changes (Alpine Tier 2 & alpha releases).

Let's leave it the way it is right now.