Comments (10)
Adding even more options (or renaming them) will only bring more confusion, and you still need to consult the documentation to understand what the options do.
I've seen similar issues already, and they're always rejected. There gotta be a really good reason for such a change, and IMO you haven't presented any.
therefore obstructing intuitive and straightforward code styling.
It's not code, it's a configuration file.
from typescript.
Or maybe there is some specific reason why those rules were named like this?
They're named such that their default values are all false
(or at least were at the time when they were named, though I don't think any have changed yet)
For example, if the default behavior is that foo
is not allowed, then the flag is called allowFoo
If the default behavior is that bar
is allowed, then the flag is called noBar
This keeps you from having to look up in the docs what the default value is - by looking at the name, you can tell.
Edit: The only flag that disobeys this rule is forceConsistentCasingInFileNames
, which was false
by default for a long time because there were performance problems associated with Node's syscalls for checking it. Once those were fixed, we changed it to true; its "proper" name would now be alllowInconsistentCasingInFileNames
but this flag is so rarely set that it's really not worth introducing a second name for or introducing a config break.
from typescript.
The self-encoding naming point is just a restatement of the bit you quoted.
from typescript.
I don't really see what the upside is here. There's already a completion list here; if you type "returns" you will see that it's noImplicitReturns
not allowImplicitReturns
.
Conversely, if two options that control the same thing exist:
- You have to figure out what it means if both exist
- You have to figure out what it means if both exist in different config files
- Basic string search no longer works
- Someone will log an issue saying you have to remove one of them "for consistency"
- Then everyone argues about which one is correct
- Someone else logs an issue saying that all options should be phrased in a way that the default value of
false
is correctly interpeted "for consistency" - Someone else logs an issue saying that they should not be renamed since the options in 5.5 were obviously good enough, and having two names is bad "for consistency"
from typescript.
Let's just remove all the options and have tsc behave the same for everyone and be completely nonconfigurable... "for consistency" 🚎
from typescript.
@fatcerberus let's just be more friendly eh?
from typescript.
@RyanCavanaugh it's just I was studying ts config docs and it appeared to me counterintuitive to have such namings for rules in the first place. You made good point about this as well.
Someone else logs an issue saying that all options should be phrased in a way that the default value of false is correctly interpeted "for consistency"
Those are small things and are easily looked up in docs, but throughout time they gather like snowball and in the end you just have to consult docs for every such details and it's not a good developer experience IMHO.
Or maybe there is some specific reason why those rules were named like this? Or this is just a simple human error?
from typescript.
let's just be more friendly eh?
@medreres That's the reason for the 🚎 emoji - trolleybus for friendly/playful trolling (and in this case I was trolling Ryan, not you). Don't take it too seriously
Those are small things and are easily looked up in docs, but throughout time they gather like snowball and in the end you just have to consult docs for every such details and it's not a good developer experience IMHO.
I would argue if you care about the options in a tsconfig at all you should be consulting the docs anyway, regardless of what they're named. The name alone can't convey all the effects a given option has, particularly in combination with other options, so what things are called is the least of your worries.
Or maybe there is some specific reason why those rules were named like this? Or this is just a simple human error?
More like "organic growth over time"; individual options are named pragmatically as they're introduced, naming preferences change, etc. etc. There's no specific reason for the haphazard naming beyond "that's just the way it worked out".
from typescript.
Note that this scheme is way better in terms of "saving you a trip to the docs" -- the completion list of options itself encodes their default values via the naming convention.
I think it'd be a lot worse if you were looking at a list of allowUmdGlobalAccess
, allowPropertyAccessFromIndexSignature
, allowImplicitOverride
, allowUncheckedIndexedAccess
, saying to yourself "Want that, don't want that, want that, don't want that" and having to cross-reference with the docs to see if you need to explicitly toggle them or not.
from typescript.
This keeps you from having to look up in the docs what the default value is - by looking at the name, you can tell.
Interesting thing, good to know, thanks :)
Didn't get the second point about self encoding naming though
from typescript.
Related Issues (20)
- Add option to throw error when `!` (NonNull expression) is used on a non-nullish expression HOT 2
- Inconsistent Type Narrowing with `never` Return Type Between Arrow and Traditional Functions HOT 2
- Class infers wrong generic parameter since e1874f3 HOT 2
- Promise returned from sync `dispose` method should not be awaited when disposing an asyc-disposable HOT 1
- Import ellision emit bug: usage of imports only in keys of interfaces does not result in those imports being elided as type-only
- `noUncheckedIndexedAccess` does not narrow properly when iterating with `for...in` HOT 4
- Omit private symbols from type HOT 6
- TS5055: Typescript includes files in "dist" folder for compilation when `rootDir` is not `./` but `./src` even after explicitly adding "dist" to `exclude` HOT 7
- Incorrect type inference for reduce method accumulator when value is number HOT 2
- Design Meeting Notes, 4/5/2024
- type inference error HOT 3
- Function lacks ending return statement and return type does not include 'undefined' HOT 6
- Inference of recursive arrow function's return type is any HOT 2
- [NewErrors] 5.5.0-dev.20240405 vs 5.4.4 HOT 25
- [ServerErrors][TypeScript] 5.5.0-dev.20240405 HOT 17
- [ServerErrors][JavaScript] 5.5.0-dev.20240405 HOT 11
- Methods with generic properties in a class cannot be assigned to unknown. HOT 1
- Is there a good way to accurately identify the cause of an error in a union type? HOT 11
- Too wide diagnostic with array spread HOT 1
- Add persian translation to docs HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typescript.