Open made-by-traxam opened 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.
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 => ...)
.
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.
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!
Soo....are we getting a ts-standard
semi-colon option or are we not getting ts-standard
semi-colon option.....?
Can anyone list what solution they found for this?
@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!
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.
@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.
@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.
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)
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.
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
@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
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 :)
@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",
Thanks 👍
Very straight forward but we will miss all the goodness of the standard tooling (cli; vscode) right?
@kelkes You can then use the ESLint cli and vscode extension :)
@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.
can I get a // at the end of every line?
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!
and uh.. rob pike was right. about everything. I'm so sorry I doubted you big rob :heart:
+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?
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.
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...
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
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?
@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
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.
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 😉
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 thets-standard
object withinpackage.json
or a similarts-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.