Linting

[nicktaras]

Hi @samwarwick and @micwallace,

Working async together at the moment, I wanted to see if we could try out Git Discussions.

Sam, you mentioned that you'd like to talk about the linting settings you recently set up. Great work on this btw.

Could we open a conversation here for the time being to share any findings and details with us.

[samwarwick]

For additional context behind this discussion see issue #163 and PR #164.

Some initial thoughts:

1. Do we have any context behind the original choice of rules defined in tslint.json? If not then I suggest maybe starting fresh with a clean slate rather than try and enforce them all as-is. There seem to be too many customisations and it is not clear what the rationale is for enabling/disabling particular rules. Incidentally, disabling all the rules defined in the current .eslintrc will reduce the number of errors (inc warnings) drastically from over 800 to around 150.
2. We should use a set of rules that is industry best-practice for open-source TypeScript projects.
3. We should try and use the same rules across all TokenScript repos as much as possible. An initial search shows that three projects in token-negotiator-examples use the same tslint.json as token-negotiator. attestation does not appear to have any linting.
4. The token-negotiator repo is full of @ts-ignore and @ts-nocheck annotations. We should endeavour to start eliminating them where possible.
5. Many of the current rule violations are due to code formatting style e.g. brace-style, no-trailing-spaces. Maybe investigate use of https://prettier.io/
6. Investigate any potential overlap with Sonarcloud rules and reporting.

[nicktaras]

1. We applied the tslint rules from another project at stl. Let's review this and apply the settings we agree upon (as per your pr (merged)). Let's also take a look at this which is a no config linter https://www.npmjs.com/package/gts (uses ESLint and Prettier) - keen to get your take on this.

Deciding which is best for our project.

2. Agree.
3. Agree.
4. Agree.
5. Agree. We should use prettier in our work flows.
6. Agree. I would think this will be a test and see scenario.

Once we run the code through prettier it will most likely correct much of these human coding style errors e.g. spacing, missing semi-colons and inconsistant formatting.

[samwarwick]

The token-negotiator codebase has extensive (and inconsistent) use of double line spacing. core/index.ts is a good example. Is there any particular reason for this convention?