semistandard with TypeScript

[made-by-traxam]

What version of this package are you using?
10.0.0

What problem do you want to solve?
Using semistandard with TypeScript.

What do you think is the correct solution to this problem?
Either supporting a semi option in the ts-standard object within package.json or a similar ts-semistandard package.

Are you willing to submit a pull request to implement this change?
Maybe. I am not familiar with this project, but I would take a look.

[theoludwig]

The main idea of standard packages is to have as less as possible configurations and out of the box great linting to catch errors early, so you don't have to make decisions, semicolon is one of them.

If somehow, tomorrow standard decided to use semicolon, I would go along, the main idea is : we don't need to set rules ourselves. Personnaly, I don't have opinion about semicolon, I could write my code with or without, I don't really care, I just want that it is consistent.

I have no idea why they created https://github.com/standard/semistandard, but I don't think it was a good idea, we should not maintain multiple packages just because everyone has different opinions, because in fact standard is completely the contrary, it chooses the rules for you, so you don't need to discuss/debate about them.

At least, that's my opinion, I will let others standard folks argue for/against this.

[flisboac]

I totally approve a new ts-semistandard package, but a flag/config in ts-standard somewhere would be nice too. In any case, there's nothing to discuss about stardardjs rules apart from the semicolon. It's the only disputed aspect of the tool; and IMHO it's not about style, but about the fact that the lack of semicolon breaks the language (in fact, your understanding of the language) in unexpected ways.

Having to cover for the gotchas that a lack of semicolons in the codebase may cause is reason enough to stay away from said practice. It also does not help when the documentation and references have condescending language, saying things like you may be trying to be too smart for innocuous language constructs like IIFEs or [1, 2, 3].forEach(n => ...).

[voxpelli]

I'm 👍 on this. Semicolons should not be what makes or breaks the use of standard. I myself use semicolons on all of my projects.

[AntonOfTheWoods]

The ENTIRE point about forcing a particular code style is to reduce cognitive load when you are looking at code. How does having a style that objectively, demonstrably increases cognitive load - particularly for beginner developers who haven't completely internalised the rules of where semicolons are required or not - useful in a standard like standard? We definitely shouldn't be having this debate, standard should definitely default to having semicolons and there should be a nosemistandard for zealots who have a bee in their bonnet about it!

[OlaoluwaM]

Soo....are we getting a ts-standard semi-colon option or are we not getting ts-standard semi-colon option.....?

[OlaoluwaM]

Can anyone list what solution they found for this?

[AntonOfTheWoods]

@OlaoluwaM , unfortunately that is the problem with zealots... The zeal is strong with them. The idea is great, and the only thing that they have wrong is this. Everything else is fine for me. Everything. This is a deal-breaker for me though.

They probably don't care about the 10% (?) of us that think this is a showstopper. If you fork I will definitely use it though!

[voxpelli]

You can always use the eslint-config directly and modify it any way you want: https://github.com/standard/eslint-config-standard-with-typescript

It’s quite a minor change for modifying to require semicolons in there.

[flisboac]

@voxpelli it's not the same. By using eslint directly, we'll miss out on standard's tooling, like the CLIs and the vscode plugin. It's a palliative solution at best.

[theoludwig]

@voxpelli it's not the same. By using eslint directly, we'll miss out on standard's tooling, like the CLIs and the vscode plugin. It's a palliative solution at best.

There is also a ESLint VSCode plugin.

[voxpelli]

While the standard suite itself could add an entire configuration layer, that would easily end up being somewhat of a duplication of what ESLint already does.

standard is meant to be an out of the box solution. For customizable approaches, using the eslint configs together with the eslint ecosystems of tools is great, as such customization is what eslint is all about (and eslint is what is used internally in standard, so it's the exact same rules executed in the exact same way)

[flisboac]

Again, you guys are missing the point. Please, don't be disingenuous.

It's not about customizability. We don't want to contest any rule (apart from semi, that is).

Given that there is:

• standard (pure JS, no semi)
• semistandard (pure JS, semi); and
• ts-standard (TypeScript, no semi).

All we're asking is for ts-semistandard to be realized.

We WANT an out of the box standard solution. To be able to use standard's CLIs and plugins, which are of high quality and easier to configure and use (because you don't customize). But the standard team didn't give an appropriate solution to the very, very common semicolon-TypeScript use case.

Standard itself is a whole lot of duplication of eslint. We just don't want to add yet another layer of configuration on top of that just to add what is effectively two lines of configuration, which are already supported (conceptually) elsewhere in standard.

Personally, today my clients and I use eslint + prettier + some preset. I just wanted to use standard directly, and avoid using eslint directly, just because I want to end styling/linting debates. I also wanted to reduce the number of tools we use during development (I.e. using just standard). But it's hard and dangerous to justify nosemi, for the reasons I explained before.

[OlaoluwaM]

You can always use the eslint-config directly and modify it any way you want: https://github.com/standard/eslint-config-standard-with-typescript

It’s quite a minor change for modifying to require semicolons in there.

Sadly it does not use eslint v8, which is the version we use at work, but I can fork it and try updating the deps tho

[voxpelli]

@OlaoluwaM We are working on ESLint 8 support, the ecosystem hasn’t been ready so far: standard/eslint-config-standard#193

[kelkes]

Any update on this? We think about ditching the airbnb config because it is driving us nuts with all the updates and conflicts. ts-semistandard would be exactly what we are looking for :)

[voxpelli]

@kelkes You can achieve this in your .eslintrc by extending eslint-config-standard-with-typescript and then adding these two lines:

    "@typescript-eslint/semi": ["error", "always"],
    "@typescript-eslint/no-extra-semi": "error",

See eg: https://github.com/voxpelli/eslint-config/pull/135/files?diff=unified&w=1#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R40-R41

[kelkes]

Thanks 👍

Very straight forward but we will miss all the goodness of the standard tooling (cli; vscode) right?

[voxpelli]

@kelkes You can then use the ESLint cli and vscode extension :)

[flisboac]

@voxpelli can we use semistandard's CLI and vscode extension? If not, why, and how difficult would it be to modify them to support semi?

Any pointers to how one can start contributing a PR towards ts-semistandard?

I'm asking because it would be nice to not have to deal with eslint directly. By reverting back to it, and adding a config file, you open the possibility for rule customization by unsuspecting users. I'd like to avoid that. Using a separate, non-customizable (or limited in config) tool is the perfect solution.

[manticorp]

+1 for this - standard with semicolons is great.

I think it's fair to say a lot of people write js with semicolons - why not just support it, like was done with standard and semistandard?

as @flisboac said:

Given that there is:

• standard (pure JS, no semi)
• semistandard (pure JS, semi); and
• ts-standard (TypeScript, no semi).

Why not complete the square for standard/semistandard and ts-standard/ts-semistandard?

Support / Lang	Javascript	Typescript
No Semicolons	✔️	✔️
Semicolons	✔️	❌

Typescript support was presumably only added because of its popularity anyway, why not support Typescript with semicolons?

[sinedied]

Would it be possible to allow customizations in the same idea as standardx ?
That way it would allow overriding the rules just to enable semicolons, and would fix this long standing issue.

[voxpelli]

Would it be possible to allow customizations in the same idea as standardx ?

That way it would allow overriding the rules just to enable semicolons, and would fix this long standing issue.

Customization's for now are best achieved by extending the eslint configuration rather than going through the standard CLI

I personally am not very fond of the standardx approach