Super-linter: Prettier for JavaScript and TypeScript

[mvolkmann]

IIUC, super-linter uses ESLint and Standard to format JavaScript and TypeScript code rather than Prettier. I think many developers will have an issue with this. Despite the name, Standard is not a standard. It's developers just gave it that name. For the past few years the trend has been to use ESLint only to check for issues and to use Prettier for formatting.

Most developers will be fine with most of the formatting that Standard performs. However, there is one controversial thing that it does. It enforces a space after function names in their definition. For example:

function myName (param1, param2) {
  ...
)

I think you will find that almost no JavaScript developer does this. So using Standard will make this change across their code bases and they will not like it.

Please reconsider the use of Standard for JavaScript formatting and instead use Prettier, which is by far the more popular option.

[bakkot]

In support of this, here's a screenshot from npmtrends.com.

I've included eslint-config-airbnb as another point of comparison, which is a more general linter than prettier (i.e. it includes code quality checks as well as just formatting). I think either of those would be reasonable choices, from the graph; standard would not.

[mvolkmann]

This chart also shows that interest in code formatting drops significantly around the holidays. ;-)

[fafnirical]

I think the combination of both ESLint _and_ Prettier, via eslint-config-prettier and eslint-plugin-prettier would work well. The ESLint configuration could extend both plugin:prettier/recommended and prettier/@typescript-eslint

[kachkaev]

Including standard js into Super Linter in 2020 feels an odd decision 🤔

Some info on problems this may cause (especially to the newcomers in coding):
https://medium.com/@WebReflection/an-open-letter-to-javascript-leaders-regarding-no-semicolons-82cec422d67d

Prettier v2 with its standard config in conjunction with ESLint is a much better solution.

[Tiedye]

Any comments from the maintainers on this issue? We can speculate on why the decision was made but without feedback it remains inexplicable.

[admiralAwkbar]

Hey all!
It was a standard we used internally but were not opposed to prettier... We need to take some work to allow for more standards to take place in the Super-Linter and would love a PR to help make it better for everyone.

As we can see from the direction so far, supporting multiple standards seems to be the right direction. We just enabled pylint and flake8 for python, so why not multiple for JS and TS... I welcome a PR to help get this rolling and would be glad to help with any issues along the way.

Thanks again for all the support.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[mvolkmann]

I think this issue should remain open until we have a PR that enables adding Prettier as an option.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[ljharb]

eternal bump

[ferrarimarco]

Prettier is a code formatter, not a linter. What we could (and should) do, is to support both. They serve two different purposes.

This is very similar to the shellcheck vs shfmt case. The first one is a linter, and lints code, while we run shfmt to check if shell scripts are correctly formatted.

[ljharb]

eslint is both a formatter and a linter, and can (and should) be used to run prettier, and thus subsumes it. That way, "linter" is "eslint", and "formatter" is "eslint --fix".

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[ljharb]

bump

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[bakkot]

@admiralAwkbar can you make it so this issue does not automatically get closed? It's annoying that it needs to be bumped every two weeks; nothing has changed since the last bump.

[admiralAwkbar]

@bakkot Ifg you could open a PR with the start of the work, i think that stops this from being closed

thanks