Migrate from standard to neostandard + Prettier

[bajtos]

I used to be a long-time Eslint+Prettier user. I was honestly trying to learn to like Standard that we are using in our repos, but I am frustrated about many papercuts:

• Most importantly, Standard does not allow trailing commas in arrays & object literals. I am frustrated by this several times a day. Require trailing commas in multiline object and array literals? standard/standard#240
• Standard allows multiple ways how to format the same code snippet. I cannot rely on "format-on-save", often I have to clean up the formatting manually.
• The development of Standard has stalled, see the discussion in Maintenance & Governance of standard standard/standard#1948
• Standard does not support linting .d.ts files

I propose we make the following changes:

• Adopt https://github.com/neostandard/neostandard with noStyle option enabled
• Evaluate Prettier and dprint, pick one of them for formatting

Decision

We decide to use neostandard and Prettier.

Repositories to update

• CheckerNetwork/site-backend
• CheckerNetwork/node
• CheckerNetwork/spark-checker
• CheckerNetwork/spark-api
• CheckerNetwork/spark-evaluate
• CheckerNetwork/spark-impact-evaluator
• CheckerNetwork/fil-deal-ingester
• CheckerNetwork/spark-stats
• CheckerNetwork/spark-participants
• CheckerNetwork/meridian-cli
• CheckerNetwork/piece-indexer
• CheckerNetwork/spark-evaluations-recent-participants
• CheckerNetwork/utils
• CheckerNetwork/cancel-stuck-transactions
• CheckerNetwork/spark-deal-observer
• CheckerNetwork/spark-rsr-contract
• CheckerNetwork/spark-stats-request-metrics
• CheckerNetwork/spark-spot-check
• CheckerNetwork/index-provider-peer-id
• CheckerNetwork/assert-ok-response

Archived repositories - no action needed

• CheckerNetwork/desktop
• CheckerNetwork/wallet-screening
• CheckerNetwork/publish-zinnia-module-action
• CheckerNetwork/w3name-update-action
• CheckerNetwork/spark-rewards
• CheckerNetwork/arweave-checker
• CheckerNetwork/simple-subnet-api
• CheckerNetwork/walrus-checker

[juliangruber]

It's easy to discuss these matters for hours, so I'm keeping my answer short:

I used to be a long-time Eslint+Prettier user. I was honestly trying to learn to like Standard that we are using in our repos, but I am frustrated about many papercuts:

• Most importantly, Standard does not allow trailing commas in arrays & object literals. I am frustrated by this several times a day. Require trailing commas in multiline object and array literals? standard/standard#240

When it comes to form, I dislike them. When it comes to function, they are keeping git diffs clean, so I'm in favor.

• Standard allows multiple ways how to format the same code snippet. I cannot rely on "format-on-save", often I have to clean up the formatting manually.

I see no problems with multiple ways of formatting something as long as all are acceptable. I'm not opposed to switching to a tool that allows only one way, if it always works well.

• The development of Standard has stalled, see the discussion in Maintenance & Governance of standard standard/standard#1948

This is possibly the most important point, as JS / TS is still developing frequently.

• Standard does not support linting .d.ts files

+1

I propose we make the following changes:

• Adopt https://github.com/neostandard/neostandard with noStyle option enabled
• Evaluate Prettier and dprint, pick one of them for formatting

Neostandard and its differences from standard lgtm!

Regarding the formatters, do you see fundamental differences, or shall we create one PR each, to compare the output? We could even base these PRs on top of each other, to see the exact difference between the tools.

[voxpelli]

This sparked an inspiration for me: neostandard/neostandard#170 Would that be of interest to you?

[bajtos]

This sparked an inspiration for me: neostandard/neostandard#170 Would that be of interest to you?

Yes! Let's continue the discussion in that other issue.

@voxpelli I appreciate that you took the time to post comments in our repo. I know from my own experience how demanding it is to maintain a popular open-source project. Thank you! 🙏🏻

[bajtos]

GitHub Actions for running Prettier and dprint:

• https://github.com/marketplace/actions/prettier-action
• https://github.com/marketplace/actions/actionsx-prettier
• https://github.com/marketplace/actions/dprint-check-action

[bajtos]

Related:

CheckerNetwork/spark-api#385 (comment)

I think we had a convention that style changes need to be enforced by a linter, so they don't need to get discussed.

(...)
Empty lines used as visual delimiters help me navigate the code faster, so they are important to me.
(...)
My takeaway is that I should investigate how to incorporate a variant of this eslint rule to our linter checks.

[juliangruber]

I personally dislike empty lines more often than not, especially if they're happening after 2 or 3 lines. It's like putting every sentence of a paragraph in its own paragraph. Let's find rules that make sense and can be applied consistently.

[juliangruber]

It would be great to include linting of SQL as well, see CheckerNetwork/spark-stats#285 (comment)

For now it could be as easy as also enforcing a line length limit on sql files

[bajtos]

The new linter should allow us to enforce EOL at EOF.

See e.g. CheckerNetwork/spark-deal-observer#12 (comment)