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