standard / ts-standard

Typescript style guide, linter, and formatter using StandardJS
https://www.npmjs.com/package/ts-standard
MIT License
464 stars 36 forks source link

semistandard with TypeScript #115

Open made-by-traxam opened 3 years ago

made-by-traxam commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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

OlaoluwaM commented 2 years ago

Can anyone list what solution they found for this?

AntonOfTheWoods commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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

kelkes commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

Thanks 👍

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

voxpelli commented 1 year ago

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

flisboac commented 1 year ago

@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.

MrTortoise commented 1 year ago

can I get a // at the end of every line?

yacineMTB commented 1 year ago

I'm curious about the decision trail that lead to an abundantly popular package disallowing semicolons and labeling it as standard. Was there a measurement of existing typescript code? I'd imagine most typescript code ends with a semicolon.

Could this be misleading unsuspecting new users about the true distribution of semicolon usage across typescript developers? Could this cause conflicts with LLM generated code, like copilot, thereby confusing new users even more?

I realize that this is probably not the thread to discuss this, and this is me asking ya'll where I might be able to trail the decision making process around this.

As always, a big thank you to the maintainer's hard work here!

yacineMTB commented 1 year ago

and uh.. rob pike was right. about everything. I'm so sorry I doubted you big rob :heart:

manticorp commented 1 year ago

+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 commented 1 year ago

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.

AntonOfTheWoods commented 1 year ago

Let's face it, standard is for zealots, and zealots don't change their mind very often. You can get the same effect without it, so just hack together something yourself. I'd wager a reasonable sum these guys will never be budged...

voxpelli commented 1 year ago

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

jaredgorski commented 2 months ago

Bumping this. Our project is large and old, and traditionally semicolon-laden. We're trying to build consensus to use ts-standard but there's some friction only around the semicolon issue. If there were a ts-semistandard it'd be a no-brainer for us.

Is this a Do or a WontDo?

voxpelli commented 2 months ago

@jaredgorski You can try the neostandard which is the open governance fork (see https://github.com/standard/standard/issues/1948#issuecomment-2138078249) that me and some others are focusing now instead: https://github.com/neostandard/neostandard

It offers TS and semi colons as options that can be combined

Tracking a dedicated CLI tool in https://github.com/neostandard/neostandard/issues/33 / https://github.com/neostandard/neostandard/issues/2

jaredgorski commented 2 months ago

Thanks, @voxpelli. Just voicing this into the abyss: Go and Rust have it right. We just type fmt and it works. Wish we had this for JS/TS.

voxpelli commented 2 months ago

The plurality of the JS ecosystem where it works across multiple environments and runtimes is also pretty interesting – and hard to ship a linter / formatter in a browser 😉