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)
- Type alias circularly references itself (5.4 regression) HOT 1
- error TS2385: Overload signatures must all be public, private or protected. HOT 2
- `export type * ...` statements in `.d.ts` files do not work (5.4 regression) HOT 4
- HTMLFormElement disallows symbol keys HOT 5
- TypeScript language service cannot find subclass references/implementation of mixin methods
- when using ts.getJSDocTags, the value of @type is not returned. Is there any solution? HOT 1
- Compiler allows narrower method signature than implemented interface HOT 6
- Allow overload signatures to have different access levels HOT 3
- Watcher recursively watches irrelevant directories HOT 11
- Auto-closing of tags within curly braces `{}` does not work when parent element is same tag in JSX HOT 1
- Undocumented breaking change in 5.5.0-beta for reference directives HOT 3
- 5.5.0 regression - importHelpers do not work with moduleResolution: bundler HOT 1
- 5.5.0 inheriting outDir: ${configDir} does not automatically exclude it from compilation HOT 3
- isolatedDeclarations wrongly enabled in VSCode HOT 3
- ESNext Set methods HOT 1
- isolatedDeclarations should not have warning for functions that have no return statements HOT 4
- Trivia ownership documentation seems to be incorrect
- `--isolatedDeclarations` allows generator functions HOT 1
- Allow `--noCheck` on the CLI with top-level `--build`
- Union in template literal simplifying unexpectedly
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.